The Process Ninja

Absence Makes the Process Grow Fonder?

I'm sorry!

I'm really sorry! I've dropped the ball...

I know that I've been off the radar for some time and this is a short post to let you know what's happening. In the last 6 months I've been working on a large business transformation project which really has sucked me dry both physically and mentally.

Overall it has been a great experience but it hasn't been without its ups and downs (like most projects). I've had the joy of playing a major part in getting the project funding approved, gone through the pain of running process re-design workshops 4 days a week for a month and the joys of modelling swimlane EPC's in ARIS amongst a thousand other things. Unfortunately this, aligned with having our 4th child back in March and publishing my cafe ninja book meant that something had to give - and this blog was it.

But the good news is that I'm back. I may be a broken down, overweight wreck with a torn shoulder blade muscle (thanks workshops) but I'm the only process ninja you've got. The good news is that I have some big plans for 2012.

Firstly I have launched a Sydney based recruitment agency specialising in the supply of process staff. Secondly I have started on my first process book, provisionally entitled "The Process Revolution". It's going to be the type of book that the grey bearded process academics will despise. I love that.

But most importantly the experiences I've gained on my recent transformation project have given me a huge amount of material that I will be telling you about over the next few months. In keeping with my new manifesto, this blog will seek to teach rather than preach.

The Ninja is back...

- TPN

Process, Learning & The Division of Labour

With every piece of new work or indeed any new experience we undertake in our lives we go through a process of learning. We may watch the task, repeat the task, read about the task - there are many different ways of learning how to do something and a thousand scholarly scientific textbooks that will tell you all about it.

But why is this relevant to process? The answer is simple - the benefits of process are fundamentally based on the way humans learn.

In a former life I was a commis chef. One day I was given a task to make the tomato concasse for one of the dishes. The chef showed me how to do it and I repeated it after him. "Good" said the Head Chef, and proceeded to give me a bucket of tomatoes to turn into concasse.  So I started to make the concasse - I took the first tomato, chopped it in two, scooped out the seeds, pressed it flat, chopped the middle out and pressed it flat then diced the tomato. Half an hour later I felt the burning eye of the chef looking at my paltry pile of tomato concasse. "NO, NO, NO!" he said and proceeded to show me the error of my ways. "First chop all the tomatoes, then scoop out all the seeds, then press them all flat, then dice them ALL!"

I didn't realise it at the time but this was my first real-life lesson in the benefits of process. As I did each step in turn I found myself speeding up dramatically. The first few I did were slow as I got my technique right, but after that I was flying, and in no time I was finished my bucket of tomatoes and was feeling very pleased with myself (until I was given a bucket of potatoes!)

What I had replicated was the concept of functional design - the same concept that was the basis of the industrial revolution. If I had, for example, a tomato concasse factory I would probably have a team that would put the tomatoes into buckets, another team to chop the tomatoes, another team to flatten the tomatoes, etc. When we split tasks into functions we break them down into simpler more easily understood parts. As they are simpler to understand the learning curve is shorter; workers can learn to do each task quickly and become very fast at doing the tasks whilst maintaining quality. Conversely if we have multiple tasks performed by one person the complexity of learning becomes greater and it is slower to complete the overall process - we introduce multiple learning curves within the process. I would also argue that when each learning curve is repeated simultaneously there is greater memory retention than when multiple learning curves exist.

Back in 1776 a very canny Scotsman, Adam Smith talked about this exact phenomenon in his famous book, "The Wealth of Nations". He talked about what he defined as the "Division of Labour" - what we call functions today - and he used the example of the making of metal pins to demonstrate the benefits of the division of labour:

"Each person, therefore, making a tenth part of forty-eight thousand pins, might be considered as making four thousand eight hundred pins in a day. But if they had all wrought separately and independently, and without any of them having been educated to this peculiar business, they certainly could not each of them have made twenty, perhaps not one pin in a day"

Adam Smith was right and it became the basis of how we do work today - functions designed to complete specific tasks. But as companies, products and marketplaces became more complex and segmented, so became the need to have more complex and specialised functions within organisations.  As process people we are now all acutely aware of the challenges that this brings for organisations to manage the flow of work across these functional specialities.

The division of labour and the specialisation of work functions provided a totally new way of working and had a major role in the industrial revolution - but it has now become both a blessing and a curse for organisations. Now and into the future the ability to manage processes across increasingly complex organisations will become imperative.

Cheers,

TPN

The Process Ninja Blog Manifesto

Recently I've been reading a lot of blogs of all different types.  Sometimes I love a blog one week and hate it the next - why? Inconsistency. 

You may not realise it but when I write this blog I'm very careful to stick to a number of my own personal rules so I've decided to share those with you today. Think of it as a policy or a process that my blog follows:

1. Only I ever write articles for this blog. Never, ever will I let anyone else write an article for it. When you read this blog you'll always be reading my words. If you want someone else to write articles on your blog you may as well not have started one in the first place.
2. I'll never put advertising on this blog (except my own!)
3. This blog remians 100% impartial. If I say I like something it's because I like it, not because someone has bought me lunch or given me a big cheque.
4. This blog is not my creative outlet. You won't find me writing articles in novelty styles because I want to display how clever I am.
5. This blog is about process - it's a niche blog. It will always be a process blog. I stick closely to those boundaries.
6. I freely admit that this blog's purpose is not only to explain process concepts, but it is a form of marketing my services (to build trust with potential clients). 
7. This blog is methodology and technology agnostic. Whilst I might rave about new software and new methods from time to time, I am 100% open to new things - all styles served here.

Cheers,

TPN

Why I'm Bored of Theory and What the Future Holds for this Blog

I'm so bored of theory I can't even begin to explain. After yet another dull, lifeless BP Trends snoozefest newsletter this month I decided it's time for action.

I read a lot of BPM blogs, and more often than not I'm reading about what we should be doing and what BPM can achieve. It's starting to get tedious reading the same old stuff about how we're a misunderstood, under-achieving discipline that can solve all of the business problems of the world. There are enough blogs out there wallowing in theory without this blog adding to it.

In short I've decided to change the focus of this blog. I'll be leaving the theory up to others from now on. What this blog will now focus on are pratical tips and tools to perform process improvement. Real-life applications of techniques to actually do work, not just talk about it.

My intention over the next 12 months or so is to blog regularly on this topic, thereby creating enough content to be able to put it all together into a book. I would love to hear from others out there regarding their own tips and experiences. If I like your tip it will likely also end up in the book (with your consent, of course).

I'm also planning on doing more tutorial style videos as well as some podcast interviews with process people who are able to pass on some tips.

So expect some pratical advice coming your way soon, but in the meantime get your practical hats on and share your tips!

Cheers,

TPN

Obituary: Dr. Eliyahu M. Goldratt 1947-2011


Sad news of the passing of a true process hero - Dr. Eliyahu M. Goldrat passed away at his home in Israel on 11th June 2011. The inventor of the Theory of Constraints, Goldratt was a pivotal figure in bringing process to the forefront of modern business thinking. He is probably best known for his excellent and unique book, "The Goal".

If you would like to pay your respects, you can leave a message here or view a tribute here.

I'll leave you with a few of his own words, which today seem more poignant than ever:

‎"I smile and start to count on my fingers.  One, people are good. Two, every conflict can be removed. Three, every situation, no matter how complex it initially looks, is exceedingly simple. Four, every situation can be substantially improved; even the sky is not the limit. Five, every person can reach a full life. Six, there is always a win-win solution. Shall I continue to count?"

Live today like it's your last.

Cheers,

TPN

Linking Process, Procedures & Business Requirements to Successful Customer Outcomes - a Business Analyst Guide

"Go out to the business and gather their requirements!"

How many times do we hear this said? 

When I hear this being it immediately fills me with dread; images of men in suits wandering through dark forests without maps, looking for mushrooms...needles in haystacks and the like (you get the idea...)

What generally happens in these situations is that business analysts go away and do just that - gather requirements - what the business thinks they want. Typically what this results in is a giant rambling document written in a pseudo business / IT speak that the business say they can't read and the IT guys say isn't detailed enough for them to build from. So the BA goes away and creates a functional spec which the IT guys love, but by this point in time it has morphed so far from what the business want, they have a heart attack when they see the final product!

"That's not what we wanted!" they say!

"But that's what you told us!" say the BA's and IT guys!

It doesn't have to be this hard. Here's how you do it:

1. Define the successful customer outcome(s)

What is it that the customer really needs? What does the business need to do to meet those needs?

2. Define the process scope

Establish what the process actually is from the customer's perspective - current state (if a current state exists!). Don't take the business's word for it - their interpretation of what a process is may be radically different to yours. Document the process at a high level (e.g. SIPOC) - confirm with the business. Tick in box from business? 

3. Define the current process

Proceed to document the process at a task level. Don't waste too much time on the as-is if you are going to change the process! Photos of sticky notes on a wall is sufficient. Tick in box from business?

4. Improve the process / define new process

List all the tasks in the current process and eliminate or improve tasks focussing on the outcomes required. If a new process, sticky note the tasks required to achieve the outcomes required with the minimal amount of activities. Don't just consider "sunny day processes" where everything goes right - consider everything that can go wrong! Look at the paths from every business rule in your process! Consider all process permutations!

5. Link Process Tasks to Procedural Steps

For each task, create procedural steps - how and why each process step is done rather than what is done. This can be done very simply in a spreadsheet ( For example my Process Ninja Workbook that utilises the CEM Method). What's more, you can then spit it into a procedural document for your staff to use for training and day-to-day operational procedures.

6. Link Procedural Detail to Business Requirements

The procedural detail helps to create a granular level of detail that greatly benefits the creation of specific requirements.  It forces the analyst to think of all possible permutations and options - it forces them to think in the context of the real world, not a gobbledegook business requirements document.

7. Link Business requirements to test scenarios

Use procedural detail and business requirements together to develop test scenarios and use cases - IT can then use these for their unit testing then they can be re-used for user testing. Easy.

8. Build it. Iteratively.

Presuming that there is actually an IT solution involved (and let's face it, there usually is), it's best to adopt an iterative (agile) approach where there are short development cycles with high business involvement. I have seen too many waterfall development disasters in my time.

So in eight steps a Business or Process Analyst can create complete traceability from the customer outcomes to the delivery.

It's not really that hard, but isn't it amazing that so many people can make it seem that way?

Cheers,

TPN

Whitepaper: Customer Experience Management & Continuous Improvement Program

My buddy David Mottershead aka The Customer Experience Coach has written a short whitepaper entitled "Customer Experience Management & Continuous Improvement Program" 

For those of you looking for some further clarification on Customer Experience Management and the CEM Method, it's well worth a read.

Cheers,

TPN

Process Black Holes

We've all experienced them. Customers loathe them. Companies don't realise they exist. They suck good sentiment out of your customers and suck money out of your company coffers. I call them "Process Black Holes".

Process black holes are where a process blackspot occurs where one of two things happens:

1. The process becomes like a pass the parcel game where the passing never stops. It goes round and round passing the piece of work between multiple teams utilising company time and money until the customer gives up (and takes their business elsewhere) or...
2. The process becomes like a magicians act - POOF! It's gone. Unresolved, uncontactable, unknown - except to your customers - who are building up into a frenzy of discontent. "They're USELESS!" you hear customers say - and they are right. My recent experience with AAMI is a classic example of this.

Process black holes exist because companies don't understand their processes, don't have visibility and dare I say it "management"  of their processes. They are more prevalent in organisations where there are processes that cross more functions (hence more breakpoints) - more opportunities for the process to fail.

So what can we do to rid our organisations of Process Black Holes?

1. Understand where breakpoints exist (visibility of process)
2. Eliminate or improve them (redesign functional teams, automate where possible)
3. Align processes to the customer (eliminate unnecessary activities)
4. Measure process failure - where are the pain points?
5. Continually improve - track successes, cost savings and improvement for the customer

Listen to your customers. Listen to your employees. Close those black holes.

Cheers,

TPN

CEM Method - An Introduction to Customer Centric Process Design

I was recently asked to put together a 1 page document to provide a brief explanation of the CEM Method (Customer Experience Management Method).

This is my attempt at it - I hope it provides a handly intro for those of us out there trying to provide some clarity on what the CEM Method does and why it's different.

Cheers,

TPN

Do Your Processes Wear Brown Cardigans?

I live my life in a constant state of battle. It's a battle against blandness, it's a battle against the kind of people who Billy Connolly would describe as "the beigeists" - the brown cardigan brigade. When it comes to process we often battle against "the beigeists" who are scared of change, who say "that's the way we do it around here", who say "no, it can't be done".

It can be a tiring battle, but it's a battle, which, as process people we need to fight - it's our job. It's our job to challenge when no-one else dares. It's our job to push change when everyone else is scared. It's our job to innovate where others prefer the status quo. It's our job to take risks when others are afraid to fail.

If we choose not to do these things, we end up creating processes in brown cardigans - bland, boring, stagnant, ineffective.

I'll end this post with a comment from Theodore Roosevelt, who put it much better than I will ever be able to:

“Far better is it to dare mighty things, to win glorious triumphs, even though checked by failure...than to rank with those poor spirits who neither enjoy much nor suffer much, because they live in a gray twilight that knows not victory nor defeat.”

'Till next time, keep daring to do mighty things...

- TPN