The Process Ninja

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

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

Of Garbage Trucks and Process Bubbles

This morning, as I drove into the street where I park my car, I was faced with a large garbage truck blocking the street (and of course, as bin trucks are magically immune to the rules of the road, he was driving the wrong way down a one-way street). Therefore I was forced to sit stationary with my indicator on in a very busy Sydney CBD street.

Behind me, cars slowly started to back up with their indicators on. Then cars coming round the corner who wanted to go straight on got stuck in the queue. The first car behind me could see the garbage truck blocking the street, but the other cars behind me could not. It was only a matter of time before the horns started honking (about 30 seconds to be precise since Sydney drivers are not known for their patience). Who was this idiot sitting in a busy street with his indicator on for no reason? Why was he blocking the road!!!?

Thankfully, across the road from me, a van full of electricians were watching from a distance - they could see the whole line of cars and the garbage truck blocking the road. So when the cars further down the line started honking their horns they started to shout and gesticulate towards the cars indicating that there was a blockage in the street. The horns stopped honking, the bin truck eventually emerged and everyone was happy again.

The same thing happens with process - often those performing the work are living in process bubbles - they see immediately what is in front of them, but they don't see what is happening before or after them in the process. So if something goes wrong they don't have the visibility of what has gone wrong and they have no idea how to fix it. But, like our friend the electrician who can see the whole process unfolding, if we take a holistic view of the process we can not only see where the pain points are occurring, but we can communicate our message across all workers in the process.

Standing back and looking at process in its entirety is not some self-indulgent, navel gazing exercise. By the nature of functional work, workers are primarily interested in getting their piece of work done (that's why they studied so hard at the university of blah de blah - so they could sit and do that particular work for the next 45 years!) But doing work and doing it well doesn't necessarily equate to good process - it's not about doing things right, it's about doing the right things.

This is why looking at the process in its entirety (the customer experience) is so essential and why it needs to be the focus of the C-level. Otherwise we all end up honking our horns for no good reason at all.

Cheers,

TPN

Can Process Save the Planet?

I'm interested in sustainability, but I'm even more interested in the linkage between sustainability and process. I would imagine that sustainability is to most process people a matter of common sense, and what many of us have been practising for years. It's all about production without the pain.

So here we are in the 21st Century and Mr Gore has informed us about what we've done wrong - namely belching too much carbon into the atmosphere. So we need to change the process (rapidly) to stop the effects. To do this there are both short and long term improvements that can be made - let's look at those:

Short-term: Reduce the amount of power we use. 

Ok, so this is a simple, quick fix, right? The less power we use, the less carbon we produce. All it relies upon is to change people's habits to reduce power consumption and wastage. For example, I should now turn off all my devices that have standby modes off at the wall socket when not in use, turn my fridge up to 4c and recycle as many products as possible.

But I'm a lazy human being. I don't really want to spend 10 minutes every day going around switching sockets on and off. I like the soft drinks in my fridge to be icey cold and I question whether my recycling has any effect if I have to rinse out all the bottles and cans with hot water (which uses power). In short, habits are hard to change and people will always gravitate to what is simplest and easiest for them. But fundamentally all of these improvements are fixing the effect, not the cause.

Long-term: Fix the cause. 

If we knew that all of the power we used was clean and did not damage the planet, we wouldn't need to worry about the difficult process of changing people's behaviour - one of the hardest things to do. If we used clean sources of power such as wind and water none of this would be necessary.

The Problem

But the problem remains the upfront cost of building wind and water turbines, of giant fields of solar panels and the like.  Much like bringing BPM into an organisation, we know it's the right thing to do, but when it comes to signing the cheque the powers that be stick their heads in the sand and pretend that everything is all right. Instead they invest in piecemeal solutions that continue to provide some benefit, but which fall well short of the true gains that could be made by fixing the cause and not the effect.

Let's hope that our politicians and corporations can make the right decisions - or the price of fixing the effect and not the cause may be our children's future.

How to Spot a Process Dinosaur

In the world of process, you have to watch out for the dinosaurs. There are many of them around. They may try to eat you up but typically they are old, slow moving and toothless. Here's how to spot them (and avoid them!)

Characteristics of the Processicus Ancestricus Dinosauricus:

• Says loudy "I'm a black belt"
• Talks about "re-engineering"
• Thinks that "Social BPM" involves having a drink at the pub
• Owns a book about the Toyota Production System
• Never uses the word "customer"
• Sticks rigidly to "their methods"
• Likes "Waterfall"
• Loves use cases
• Thinks BPM equals technology
• Draws processes in powerpoint
• Views processes in isolation
• Continually says "I'm still documenting the as-is"
• Creates phone book sized documents
• Talks about "actors"

and their most obvious characteristic

• Delivers nothing of value to the business or the customer

Cheers,

TPN

Continuous Improvement - Because Stupid Stuff Happens All The Time

If anyone is in doubt as to why improvement has to be continuous, the simple explanation is that stupid stuff happens all the time: mistakes are made, things are rushed, ideas badly conceived, ideas even more badly executed and then there are those people things - they keep making mistakes because for some unknown reason they aren't perfect. This doesn't even take into account the numerous amount of organisational activities that are going on on a daily basis that contribute absolutely nothing.

I stumbled upon a classic example today from my car insurer youi. I have been quite impressed by Youi, so when I came across this classic example of "stupid stuff" I was surprised.

Youi were proactive enough to send me a text this morning asking me to log into my online policy manager to update my credit card details as the card was due to expire. Great!

So I go to the Youi website to login:

Like most people in the universe I neither know nor carry around the unmemorisable three million digit insurance policy number. But why should I have to? Why can't I log in with my e-mail address i.e. something that I can easily remember? (And as an aside, why are insurance policy numbers always so long?) This serves only to create extra work for Youi staff who have to respond to e-mail or phone enquiries.

But wait! There's an "I've forgotten my policy number" link - fabulous!

So I click on the link and it takes me to a little form:

Everything is wonderful until I get to the field that says "Please enter a valid policy number". I try to skip it - after all isn't that why I'm filling in the form - to get my policy number? No! It's a mandatory field and I can't submit the form without it!

So to obtain the policy number that I don't know, I have to fill in a policy number that I don't know. Genius.

So if you or anyone else you work with ever doubts the need for constant vigilance, feedback mechanisms and a cycle of continuous improvement - just tell them about the multi-million dollar insurance company that was creating needless cost for itself.

If stupidity is the illness, continuous improvement is the cure.

- TPN

Carry The Wounded And Shoot The Stragglers

BPM Guru Michael Hammer once famously said that in re-engineering they would "Carry The Wounded And Shoot The Stragglers". Whilst the cutback and redundancy culture of the 90's re-engineering era gave birth to the horrendous process PR that we are still battling today I believe that Hammer's quote is still relevant today in terms of change management and process.

I'm a strong believer in Change Management as the right-hand man of process. If process is to succeed we need change management - not at the end, not in the middle, but throughout the entire duration of the process change. We need to sell process and what it can deliver and we also need to make people understand and be comfortable with the changes that are coming. But change management can also be exhausting; there are always staff who "don't get it" and who never will and there are always managers who try to assassinate the process change.

This week, interestingly, engagement expert James Adonis talked about "Adherance to Policies and Procedures" where he talks about using "Hard Power" and "Soft Power":

"When trying to get your employees to adhere to policies and procedures, you have hard power and soft power at your disposal.  Hard power is negative motivation.  This is when you intimidate employees into compliance.  You issue warnings, reprimand them, and offer greater (or fewer) tangible rewards.  Soft power is when you get them to follow a process via the art of influence".  

Both of these methods are applicable to process change management - always start with soft power, such as using 5 simple steps to communicating process change. If soft power isn't working for you, that's when it's time to switch to the hard stuff.

So in change management we carry the wounded and talk softly to them, heal their wounds and rehabilitate them so that they can join the good fight. But if they won't take their medicine, won't keep up and won't join the good fight, it's time to shoot the stragglers...

- TPN

Don't Dictate the To-be Process, Facilitate the To-be Process

In my opinion there are few worse things in the world than a consultant in a shiney suit turning up at your business and telling you what to do. It's arrogant, unnecessary and gets the customer offside from day one.

Last night I attended the Sydney BPM Link meeting at where one of the speakers was John Jeston, Partner at The LiTMUS Group. When John was asked by an attendee  whether he "tells people what they should do" with regard to the to-be process I was glad to hear him say that he would never tell the client what to do.

I am exactly in agreement with this approach. I find it abhorrent when process consultants walk into a business and start to design to-be processes that they think are correct. I believe that a good process person facilitates the to-be process, but they never dictate to the customer what that process should be. Often the to-be process may be obvious to the process facilitator - but it is vitally important that the customers come to the conculsion on what the process should be with the help of the facilitator.

One of the great benefits of the CEM Method I use is that it actively involves the workshop participants in designing the not only the as-is process and the to-be process but it helps the customer define the actions required to get from the as-is to the to-be.

It's your job to guide your customers in the right direction, not push them.

- TPN

Lessons from a Process Project Failure

Recently I worked on a process project that I consider to be a failure. In the eyes of the company involved, however, it will probably be viewed as a great success.

Success or failure can be bizarrely subjective sometimes - mostly due to complete ignorance of what a process project should achieve.

 

Here's what I deemed to be the reasons for its failure and what lessons can be learned:

Failure 1 - Too expensive

While the particular company had oodles of money to spend the eventual cost of the project was approximately 10 times what it should be.  This was due to the fact that the company was mentally locked-in to old ways of thinking and could not see past developing new systems in the manner of which they had previously done it - hardcoded, costly and slow.

Lesson 1

Don't be locked into old ways of doing things. Utilise new software solutions to provide agile systems that are flexible today and tomorrow.

Failure 2 - Too slow

6 months after inception the project had not even started to be developed. Actually it hadn't even been resourced. Old, beureaucratic management processes with no agility meant that projects had to follow a stuffy development cycle with 150 rounds of sign offs to get anything done. As a result nothing got done. What could have been done in 3 weeks took 3 months.

Lesson 2

Realise the cost of beureaucracy and unleash staff by empowering them to make decisions. Embrace "freedom within boundaries".

Failure 3 - Not Utilising Staff Experience

Whilst some highly experienced and capable resources had been engaged to work on the project it was clear from day one that they would neither be allowed to use their experience or their initiative. Staff were treated like junior BA's and PA's. Management paid lip service to their suggestions. 6 months on, all the staff had left.

Lesson 3

Treat staff with respect and allow them to utilise their experience. Managers need to swallow their ego's.

Failure 4 - Not Involving Stakeholders

Throughout the project stakeholders were treated like lepers - not to be spoken to or touched in any way. As a result they became disengaged and skeptical of the direction of the project. "buy-in" was disintegrated.

Lesson 4

Involve stakeholders from start to finish. Make them part of the project. Sit with them, involve them, communicate with them. A few workshops and a slap on the back is not enough.

Failure 5 - Forgetting The Customer

No matter how many times I tried to bring up the customer experience, the concept fell on deaf ears. Customers were not advised or consulted. If the stakeholders were treated like lepers then customers were treated like they had bubonic plague. There was to be no consultantion with customers.

Lesson 5

Customers are an organisation's reason for being. If we fail to take into account the customer experience we simply fail. Customers must be involved no matter how afraid we might be of what they will say. The implications of what they will say will never be worse than the danger of us not communicating with them.

Failure 6 - Technology Defining Process

It was clear from the start that the project was dangerously forcussed on (old) technology being pushed at the business. Rather than look ahead to find new and innovative solutions the project was trapped in the mire of inflexible legacy systems that were limiting the company's ability to do business.

Lesson 6

Technology is a tool for achieving business success - nothing more. Technology should not be pushed to the business - the business should define what it wants, and receive the technology it needs. Customer > Business Strategy > Process > Technology. It's that simple.

Failure 7 - Shyster Consultants

When things started to go wrong (i.e. all the staff left) the panic button was hit and in came an highly paid consultant. Rather than delivering tangible project benefits the consultant swanned around telling other staff what they should be doing (in meaningless management speak riddles) and re-hashing previous work into a number of new and equally useless powerpoint presentations.

Lesson 7

If you are going to spend money on consultants, ensure they have a history of being able to deliver, rather than just talk and create powerpoint presentations. Focus on them demonstrating experise, not legalese.

Whilst this is not an exhaustive list of reasons for process project failure, this is a REAL list of reasons for process failure based, sadly, upon my own experience.
 
It doesn't have to be this way - and I, for one, will not be putting up with it again.

You shouldn't have to either.

- TPN