The Cupcake Strategy – Business Strategy for a Startup Business

Cupcake by zigazou75 CC-by-2.0

Introduction

Cupcake by zigazou75 CC-by-2.0
Cupcake by zigazou75 CC-by-2.0

I’m often talking business strategy and how it can apply to any business no matter how new or how small. Strategy should be applied to every business but it’s a shame that the closest many business owners get to it is a business plan for a bank loan. This is even worse when they may have need a lesser amount or even avoided the loan completely had they planned differently.

What I’ll Cover about Business Strategy

I can think of a few TV series where one of the characters set up a restaurant or a cupcake business. There’s something about that concept that must correlate with our desires. I see many new cake businesses, I know several people who have all separately and independently started into cake-making businesses. So based on that comes the new series of articles.

I’m going to review the current state of business strategy thinking and apply it to a hypothetical cupcake-making business. It’s a free series of articles and the majority of the lessons should be applicable to other industries. I’ve chosen cupcake-making because of its popularity and the ease of understanding.

Whether we want the job or not, it’s easy to put ourselves in the position of cupcake business owner. In its simplest form, we all know that you have to buy baking products, mix them according to a recipe, put them in an oven, remove them when cooked and sell the cakes. Over the series of articles, we’ll see how that simple concept could translate into a cupcake-making business.

What You’ll Learn about Business Strategy

  • How business strategy can be applied to small businesses, especially new and start-up small businesses.
  • What tools you can use to evaluate and validate your business ideas
  • What tools can help you to steer your business in a different direction
  • Some insight into how this can be applied to larger organisations and companies

Most importantly, you’ll be in a position to learn:

  • How to think analytically about your business idea and be more informed about the decisions you’ll make

Questions

Do you have a strategic idea that you’d like to see considered in this series, let me know. Either sign-up to the newsletter and ask there or contact me.

Positive Persuasion at Work for a Charitable Organisation

RNLI Flag by L2F1 (CC BY 2.0)

Introduction

RNLI Flag by L2F1 (CC BY 2.0)
RNLI Flag by L2F1 (CC BY 2.0)
Cialdini’s book on Persuasion is a great introduction to the forces applied on us by others to convince us to change our ways, e.g. buy their product. I see the ideas implemented the more and more I look. Often I think people have stumbled on the ideas, other times I feel that the interaction has been designed that way. When they’re designed in a transparent and above-board manner, then the interaction is a thing of beauty to behold. The following interaction displays the 3 principles of commitment and consistency (that’s one principle), reciprocity and social proof.

RNLI Blackpool

I visited the RNLI station in Blackpool a week ago and found an activity station of great interest. It featured 3 boxes each with a title. The twist on these normal community-involvement voting boxes was that instead of a passive vote where the company (e.g. Waitrose) donates money to the charity based on the number of tokens in the boxes, these boxes were all about what the voter would do, e.g. donate money or volunteer time. Although the vote upstairs only required picking up a token and then placing it in a box, it starts the commitment process.

Downstairs is where the consistency part of commitment and consistency principle comes into play. To keep your actions and your statements (i.e. having said you’ll donate when you were upstairs) coherent, then you’ll feel more compelled to donate when you’re downstairs. There’s no coercion here, it’s helping people follow through on what they’ve said they will do.

The reciprocity principle came into play upstairs. You were provided with a token and free entertainment. Naturally, you feel you want to return the favour by contributing something of value.

The social proof principle comes into play when there is a group of visitors. The more that place tokens in the boxes, the more will follow and do the same. Imagine a coach-load of tourists passing through the RNLI station and effect that they’ll have on each other.

Summary

Overall, it was a great example of how to use the principles properly.

So we’ve covered 3 principles and I hope you’ve learned something about how these principles can be employed in an ethical manner.

If you want to show your thanks, then donate to the RNLI. The RNLI station at Blackpool is well worth visiting for the experience if you want to donate in person.

Want to learn more?

You can learn more, including more detail and examples on the principles mentioned above and the other 3 principles of Scarcity, Authority and Liking in Robert Cialdini: Influence: The Psychology of Persuasion

Be The Customer

Be The Customer

Introduction

Be The Customer
Be The Customer

I really believe in getting customer input, especially before you build you product or service. Lean Six Sigma includes the concept as part of Voice of Customer, Lean Startup and similar methods include the concept within Customer Development. If you work for an existing organisation that currently delivers products/services rather than a start-up, sometimes it’s easier to actually be your customer than to gather their input.

Many companies try to get closer to customer needs by using mystery shoppers. Again, depending on your product this avenue may not be necessary.

Examples

I’ve been reminded of this many times when I see a process that just doesn’t make sense for the customer, but looks like it would have made sense for the person working in the office who created the process. I’ll discuss three examples below:

Traffic Wales

I was driving back from Llandudno on the A55 and a roadside sign flashed a message of “Incident after junction 32”. These IP-enabled roadsigns are a common sight on most of Britain’s motorways allowing staff to remotely update the message on the sign. But this sign was odd for two reasons. First, it was an A-road so to provide a junction number on the warning signs rather than a destination is not that common a sight. This made me wonder whether the message referred to the road I was driving on now or a road that we would intersect with, e.g. M56 or M6. This was compounded by the second oddity; there were no junction numbers on the static road signs nor on my car’s satnav/GPS. I was left confused by a message that may have a large bearing on my journey or none at all. To this day, I still don’t know where the incident was, I was fortunate enough to have an incident-free journey on my route home.

HR department

I worked for a good ICT company almost two decades ago and another one a few years later. In between, I worked for a large consultancy. Both of the ICT companies were moving into the consultancy arena with more mobile staff taking on more business change and less pure ICT activities. As an employee, I found the treatment of mobile staff to be very different between the ICT companies and the consultancy. The policies – such as how much could be spent on hotels, time before you could claim for certain types of expenses, what time the head-office closed in case you were in another country needing assistance to get home – were all written by HR staff from headquarters in both the ICT companies. That made for some interesting events where there were no hotels available (not just a question of standards) for some meetings or no-one to help out when the hire car’s broken down and it’s better for everyone (especially your corporate client) if you change plans. In contrast, the policies at the consultancy were written by consultants who travelled and operated by HR. That made for a much more reliable service, one that gave the mobile staff much better support while travelling.

Local Roads

Local authorities in England inherit the duty to maintain local roads. That involves the scheduling of roadworks and should involve working with national agencies so that motorway roadworks don’t cascade into the local road network. I can think of at least two towns that have had concurrent roadworks on every route out of town, adding 1 or 2 hours to journeys each way. No doubt some of the council officials were involved but probably hadn’t thought of themselves as customers of their own service.

Be The Customer

Both companies could do with thinking about their customers and trying to use the service as a customer would. I think of two actions when I think of being the customer:

  1. Actively take time out of your product development to go and experience what it’s like as a customer. So go and drive on the road a few times a year and watch what messages, signs are being given, what the spacing of roadworks are.
  2. Engage your staff to think like customers as they go about their days and then to inform the teams responsible of what they find.

In the case of the the road sign, the HR policies and possibly the roadworks, the events were initiated by people in the office. All of these could have been improved by being the customer. I saw the difference with the HR policies, it was a much more comfortable experience recognising that as a mobile employee, you were often away from home and family. The issue with roadworks is probably more one of common sense, rather than being a customer. Why block every main artery and some of the minor ones? The act of being a customer creates a better mindset, by forcing you to think in more basic terms. It’s not about the difficulties in the office, takt time or production control, it’s about what you experience as a customer. I’m pretty sure that Traffic Wales would have had the equivalent of England’s Highways Agency Officers driving up and down the A55. Unfortunately, having them think what it’s like being a customer may not have helped too much since they would have to unlearn what they know as part of the job, e.g. abbreviations, road junction numbers, etc. In their case, they’d still have staff who are less integrated to the operation, e.g. new starters, who could be asked to act as the customer on their way to work and back.

In short, this is a variation on the typical lean battle cry of Gemba, “go to where the work is”. In addition, Be The Customer.

Introducing the new Questions and Answers

Starting this week, I’ll be answering your questions on Lean and Lean Startup and how they can be applied to the public sector. I’ll also answer questions on wider subjects of business transformation and change management, although I expect most will relate to Lean in public sector and/or Lean Startup in existing organisations.

I’m assuming that any questions you ask me are public and can be posted on this site and publicly responded to. If you need a private response, let me know in the question and I’ll treat it so.

The idea behind this is to share some of my experiences, e.g. how I’ve overcome some of the typical obstacles to change or what to expect when transforming a public sector operation.

You can keep up-to-date with the questions and my answers by subscribing to the newsletter in the simple form below. Take the opportunity to ask a question in the form.

I hope you’ll join me in this.

thank you

Alan

Subscribe to our mailing list

* indicates required




Email Format

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

Fundamentals of Process Mapping – Introducing Subprocesses Part 3

In the previous diagram, I’ve put two crosses, not part of any standard. I’ve used them to highlight what’s wrong with the Choose Book process as depicted above. The second of the crosses is easiest to explain.

The process step of Scan Book more properly belongs in the Pay for Book process. We can see it in the Pay For Book process, so let’s keep it there. If it’s also in the Choose Book process, then we’re duplicating actions. Someone following the overall process in the diagram above would end up scanning books twice. That’s not right.

The cross on Take to Pay Desk is more awkward and shows where we cross the boundary between science and art. Does Take to Pay Desk belong more to selecting a book or paying for it? My view is that it should be in Pay for Book. Since the book is chosen at the point that the customer picks up the book. Anything after that (apart from putting it back in the bookrack again) is beyond the scope of choosing a book. Two other scenarios come to mind that reinforce the fact that it’s in the wrong process above:

  • if they were going to steal the book, they wouldn’t take it to Pay Desk.
  • if they were going to read the book in the store, as is getting a lot more common-place in the UK, they wouldn’t need to take it to the Pay Desk.

In both the above scenarios, the process of Choose Book would still be relevant. In the second scenario, the customer would still have followed the Choose Book process.

I’ve simplified the diagram by removing the Take to Pay Desk and Scan Book process steps and inserting the Take to Pay Desk process step in the Pay for Book process.

Remember: you won’t see the processes on the same page. That’s just so I can present the relationships between them.

Process Mapping Fundamentals – Introducing Subprocesses Part 2

If you look at the Pay for Book process-step in the top row of the above image, you’ll notice I’ve included a small image of the Pay for Book process. The use of colours is just to help me show how the processes fit together here. It’s incredibly rare to have the process and the more detailed process on the same page. In fact, I can’t ever remember doing that apart from when I’m showing the relationships between processes in articles such as this one.

I mentioned that the Process Starts and Process Ends are the glue because the detailed process (the lower one in the above diagram) should be able to fit into the main process (the upper one in the above diagram). It should do this without overlapping into any other process steps. Choose Book will also have its own detailed process map.

Here’s an incorrect example highlighting Choose Book and Pay For Book.

That Choose Book process relates to the Choose Book process step. Actually, maybe I should state that the Choose Book process is the Choose Book process step. It’s the same thing, just different views of it. One view shows more detail than the other.

Process Mapping Fundamentals – Introducing Subprocesses Part 1

Introduction

Processes can be broken down into more detailed processes. In this article, I’ll take one of the process steps from the previous article and look in more detail about how it connects to the other components of the process.

Some Perspective

A key feature of any workflow system is that you should be able to look at the system from different levels, e.g. a director’s view of the system may only show 5 or so process steps and cover what it takes 10-200 people or more to perform. A user’s workflow will probably require several process maps, each relating to the different processes that they perform on a daily basis and some that are less frequent. The solution’s workflow could feature many process maps, perhaps describing the user interfaces and the core system’s interfaces with external solutions.

Each map communicates to its intended audience. That means that we, as analysts, have to write for that audience. Fortunately they all follow the same basic principles. They should all relate to each other, if they don’t, then there’s a gap that needs to be addressed.

Using the 3 levels above, we should be able to look at the director’s level process model and delve into the process steps. Say we look at the process step 1 in that model, we should be able to find a user-level process model that shows us the detail of that step. Similary when looking at the user-level process model, we should be able to look any process step and see more detail in the process described in the solution workflow.

So how do the processes fit together?

The first point to understand is that most process steps can be a processes in their own right, usually with more detail. Rather than have all that detail on every diagram, it’s more common to display a box for the process step and that refers to a more detailed process map for that step.

Let’s take the Buy a Book process from the previous example and work through that.

The Pay For Book process step includes a number of its own steps when it’s viewed as a process. We’ll take a very simple concept of paying by cash. The same principles apply to paying by credit card, just that there’s more involved in that process.


Like all of these processes, real-life is more complex. For instance, scanning the book would display the price on the till. There’s also more happening with process cash payment, e.g. what about giving change back? I’ve changed to yellow just so it’s easier to show the different levels in the following diagram.

The glue is the Process Start and Process End points. These connect to other processes.

Note the name of the Process Start? It’s the same text as the process step in the original Buy A Book process. When reading Buy a Book, you may want more detail about Pay for Book, so look for the process model entitled Pay For Book and it should have one Process Start with the same name. The End point again assumes that the process has been completed. If we were looking at more detail, it could be that the buyer couldn’t pay and so didn’t purchase a book. For the moment, we’ll leave that outcome.

Process Mapping – Introducing Decision Points

In the previous article, I introduced a basic process map consisting of a process start point, a process end point, two process steps and connectors.

It’s rare that a process map is a straight line like that simplified process. There are usually options which can take the process down different paths.

In the case of our book-buying process, we may want to ask the customer if they want the book gift-wrapped as part of free promotion.

Decision Points
The most common symbol for a decision point is a diamond (or a rhombus for the pedants out there). Similar to the process steps, the decision point is linked by a connector into the diamond. The difference is that the decision point should have at least two connectors coming out. It’s generally best to label each connectors with the outcome that it represents, otherwise the reader is guessing which outcome they’re looking at.

So back to the gift-wrap example.

As you can see, I’ve added the following items to the previous diagram:

  • Decision point of Gift-wrap
  • Outcome of Yes
  • Outcome of No
  • Gift-wrap Book process step

It could be that there are more outcomes from the decision point. Or that the decision point leads to another decision point, e.g. Red or Blue wrapping paper? More complex would be that some points are only available.

Notation
I’ve already mentioned the common use of a diamond for the decision point and that outcomes should be labelled. In addition, the text inside the Decision Point should be a question. And the outcome labels should be appropriate as answers to that question. Sometimes we have to abbreviate the responses due to space. Bear in mind it’s all about communication, so think whether the readers will understand the abbreviated labels.

Ideally I’d have had a longer label for the decision point in the above example. My excuse is that I’m creating the maps on desktop software, then having to export in a way that works for this website. That’s not the way I’d normally work, since I’d usually use the process modelling software that the client has bought into. I could still get a longer label but the process map suffices to show how decisions are depicted.

You may also see a decision point duplicated at the end of the options. i.e. the process would show a decision point, then the options/outcomes, then bring them all back to a further decision point (often empty). This just shows that the decisions have been resolved and that there’s only the one path forward from that point on. This depends on the modelling standard you subscribe to.


Here’s an example of that. I find that the additional decision point can confuse less-technical, more business-oriented readers. It also takes up more space on the screen or paper. So I tend not to use it that often or until a project is at a more technical stage.

The Most Common Mistake
The most common mistake I see in process mapping is that there aren’t enough outcomes in the process map. The analyst may have assumed that the answer is yes or no. Often there are other outcomes, e.g. don’t know, timed-out, incorrect response, didn’t understand the response. It becomes more of an art than a science as to how many of these outcomes are included. Bear in mind that as more time passes and the project moves forward, then more of those outcomes should be documented.

Note the Ending
In the case of the gift-wrap example, the Process End is the same ‘Book Bought’ whichever outcome is taken from the decision point. That suits us because the Process of Buying a Book is still completed, regardless of whether the customer wants the giftwrap or not. It is possible to have different endings depending on the outcomes inside the process, we’ll get to that later.

Is that sufficient?
In short, no. It’s a start. Some of the first few steps in the process mapping journey. There is more to learn. For instance, we’re not depicting who does what, what else they do, the details of paying for a book, or even what happens if we charge for the gift-wrapping. I stated it was a free promotion earlier since it allows us to focus on the decision point itself. I also want to go into more detail about how process steps relate to processes.

Checklist for decision points

  • Is the symbol noticeably different from process steps or other items? (actually not necessary, but very worthwhile if the process modelling tool allows it and most diagramming tools do).
  • Do the decision point have enough outcomes?
  • Is there a label on each outcome?
  • Does every decision point have a question as its label?
  • Do the outcome labels relate the decision point question?
  • Do all the outcomes connect to other items? (e.g. process step, process end, decision point)

Modelling Standards
I mentioned Modelling Standard above. I refer to standards such as BPMN or UML, specifically UML activity diagrams. In this series, we are starting with basic examples, moving towards depicting models conforming to those standards. The main thrust is to get the basics right and point out some of the common mistakes along the way. Watch out for different terminology, in BPMN the decision points are referred to as Gateways.