Blog

I’m Perfectly Imperfect, Flawlessly Flawed

Following on from yesterday’s post featuring “lowest common denominators,” I was once assigned to a project in which “flawless execution” was a stated requirement.

Not a goal, or a vision, or something to strive for – there it was in black and white, right in the requirements document: Fail to execute flawlessly and we may as well not have bothered even showing up.

If I could have gotten away with just walking out immediately then I would have. Instead I snidely commented that I’ve never done anything flawlessly before, so I was excited to start.

Everyone stared at me blankly for thirty seconds and then we all moved on to the next item on the agenda.

Blog

The Two Most Poisonous BPR Dangers

A little while ago when I wrote about The Monkey Parable, I promised that Iā€™d write more about what I see as being the two most poisonous BPR dangers youā€™ll face when attempting to re-engineer and optimize business process, at least from my experience of attempting to do so.

image

Well friends, the time has come. Join me, wonā€™t you, after the break.

ā€œThis is How Weā€™ve Always Done Itā€

The first danger I alluded to in a not especially transparent way when I relayed the monkey parable to you all: we do it this way because this is the way weā€™ve always done it.

This used to be an extremely prevalent problem in my organization. Less so these days thanks to a senior leadership team that specifically calls this thinking out and tackles it head on ā€“ but even so this kind of thinking still exists where I work, and Iā€™m 99% confident in saying it exists where you work too.

Essentially the thinking here is that weā€™ve been doing something the same way for 20 years then there has to be an excellent reason for that, otherwise something would have changed long ago. The fact that nobody knows the excellent reason is seen as largely irrelevant.

So from a Business Process Management / Business Analysis perspective, how do you combat it? Itā€™s all about perspective. Itā€™s unlikely that any of the truly important processes in your organization are completed by a single person, and that makes perfect sense: somebody who shapes sheet metal to create a panel for a vehicle would be an extremely skilled craftsman, but that doesnā€™t mean they have the expertise to build a gearbox. Too often though we have too narrow a focus when we look at business processes.

Focus is only good if you know youā€™re focussing on the right thing, and to understand that you need to take a step back and take a more holistic view. Itā€™s in doing this that you can start to break down those ā€œthis is how weā€™ve always done itā€ misconceptions, because they most commonly arise from a misunderstanding of the up- and down-stream impacts of the work a particular person is doing. If youā€™re looking for transformative change then my advice every time would be to get subject matter experts from every aspect of a process together to talk the whole thing through ā€“ I guarantee youā€™ll find waste, and probably lots of it. And if your process doesnā€™t start and end with the customer (in purest sense of the word), youā€™ve defined it too narrow a way for this phase of your work.

Catering to the Lowest Common Denominator

ā€œThink of the dumbest person you work with, and letā€™s build a process they can complete with ease.ā€

Iā€™ve personally uttered those words in the past during sessions Iā€™ve run as part of BPR initiatives, and I suspect Iā€™ll do so again in the future. Getting people to think like this is fine, but itā€™s a powerful tool and you have to be very careful not to misuse it.

If youā€™re talking about designing a user-interface perhaps, or discussing building automated error-proofing functionality into a system ā€“ absolutely, letā€™s make that stuff as intuitive (read: idiot-proof) as possible.

All too often, this gets taken too far and results in masses of waste and redundancy being built into business processes. If I complete a task that I then hand off to somebody else only so that they check every aspect of my work, thatā€™s a problem. A big one. The company would be better off taking my paycheque every two weeks and burning it. They could use the fire to help heat the building, and they also wouldnā€™t have to deal with the massive attitude problem Iā€™d develop through being part of a system that places no trust in the work that I do. The result of which is the problem becoming self-perpetuating: Now Iā€™m not only disengaged, Iā€™m not accountable for my work in any kind of meaningful way ā€“ if I do a bad job then the person whoā€™s checking everything I do will fix it anyway, so what does it matter? So of course I do a bad job, why would I bother trying to do anything else? ā€œHa!ā€ say the powers that be, ā€œtold you it was necessary to check over everything. We find errors in 65% of the tasks that Jason completes.ā€

So how do you tackle this from a BPR perspective? Two ways. Firstly, you have to trust people to do the work they were hired to do. Thatā€™s easier said than done sometimes, but as a Business Analyst (probably) dealing with people’s performance issues (whether perceived or real) and coaching is unlikely to be within your remit anyway, so why make it your business? If thereā€™s one thing Iā€™ve learned about people itā€™s that you get from them what you expect to get from them. If you have low expectations and treat people like idiots, you get back poor performance. If you have high expectations and provide people with autonomy and, most importantly, accountability, then youā€™ll get back the high performance youā€™re asking for. Quite aside from all that, if the ā€œlowest common denominatorā€ that you have in mind when youā€™re designing a process really does require that a second person checks over everything they do then you should fire that person and start over with a new ā€œlowest common denominatorā€ in mind.

Now that we have an accountable, high-performing workforce completing our process the second thing we need to do is allow for some mistakes. If we demand perfection from the output of our process then rework and unnecessary checks will almost inevitably be the price we have to pay within the process. Six sigma (which is what weā€™re all striving for these days, right?) allows for a defect rate of 3.4 parts per million, and that comes from the world of manufacturing where machines are doing much of the actual work. If your people-based process really expects that level of accuracy then my recommendation would be turn your attention away from increasing the processā€™ sigma level and figure out a better method of handling expectations and dealing with the inevitable defects instead.

Blog

Home Server Setup ā€“ Useful Links

Iā€™ve mentioned in a couple of previous posts that Iā€™ve refreshed my home server recently. In setting everything up I spent a lot of time googling around looking for information on how to do things that for the most part Iā€™d done before on my previous server.

To help me avoid future googling if/when I need to go through this process again, Iā€™ve been creating a whole bunch of bookmarks this time around. I thought Iā€™d share them in case theyā€™re useful to anybody else.

oVirt Hypervisor

Linux Server

Windows Server

Blog

Learn Version Control with Git

Recently I’ve been reading the eBook “Learn Version Control with Git” online, and I’d recommend it.

image

I’ve been using Git for a while, but certainly not to its full potential, and not even really for its intended purpose. The book is great because it:

“…doesn’t require a master’s degree in computer science to read it. It’s aimed at beginners of programming, at designers, at project managers… It tries not to require too much prior knowledge on the technical side. It tries to go slowly.”

You can read it online for free, or purchase it in PDF, ePub or Mobi format for your device.

Enjoy!

Blog

Why Great Ideas Always Come In the Shower (and How to Harness Them)

Never in my life have I had a good idea in a meeting.

All my good ideas come at other times. During my commute, when I’m out for a walk, and – of course – when I’m in the shower.

Why Great Ideas Always Come In the Shower (and How to Harness Them)

Blog

The Monkey Parable

My friend Andrew told me what I now call ā€œthe monkey parableā€ several years ago, and itā€™s stuck with me ever since.

There are five monkeys, locked in a cage. Thereā€™s a banana hanging from the ceiling and a ladder set up on the floor.

Predictably, one of the monkeys immediately starts to climb the ladder in an attempt to get the banana, at which point *FOOOSH* the monkey gets sprayed with icy-cold water from a hose. This repeats as the other monkeys try climbing the ladder, only to each get sprayed. The monkeys give up, resigning themselves to the fact that the banana is unobtainable.

Next, one of the monkeys in the cage gets replaced. The new monkey sees the banana and the ladder and starts to climb. Right away the other four monkeys, familiar with the consequences grab the new guy, pull him off the ladder and beat him. New guy gets the message ā€“ the banana is off-limits.

This process then repeats as, over time, each of the monkeys gets replaced. Each new monkeyā€™s first instinct is to reach for the banana, at which point heā€™s immediately grabbed and pulled away by his peers.

Eventually, none of the original monkeys are left. There are still five monkeys in the cage, but none of them have ever been sprayed by the hose, and none of them are attempting to get the banana hanging from the ceiling.

When another new monkey is introduced to the cage and is prevented from attempting to reach the banana heā€™s confused, and he asks the existing monkeys why they beat him when he tries. The other four monkeys shrug their shoulders.

ā€œDonā€™t know, but thatā€™s the way we do things around here.ā€

You may be able to draw parallels between this and process improvement initiatives youā€™ve attempted to run. I certainly can. This parable illustrates one of what I believe are the two most poisonous BPR dangers, and Iā€™ll be writing more about them both in the not too distant future.

Watch this space!

Blog

The Monkey Parable

My friend Andrew told me what I now call ā€œthe monkey parableā€ several years ago, and itā€™s stuck with me ever since.

There are five monkeys, locked in a cage. Thereā€™s a banana hanging from the ceiling and a ladder set up on the floor.

Predictably, one of the monkeys immediately starts to climb the ladder in an attempt to get the banana, at which point *FOOOSH* the monkey gets sprayed with icy-cold water from a hose. This repeats as the other monkeys try climbing the ladder, only to each get sprayed. The monkeys give up, resigning themselves to the fact that the banana is unobtainable.

Next, one of the monkeys in the cage gets replaced. The new monkey sees the banana and the ladder and starts to climb. Right away the other four monkeys, familiar with the consequences grab the new guy, pull him off the ladder and beat him. New guy gets the message ā€“ the banana is off-limits.

This process then repeats as, over time, each of the monkeys gets replaced. Each new monkeyā€™s first instinct is to reach for the banana, at which point heā€™s immediately grabbed and pulled away by his peers.

Eventually, none of the original monkeys are left. There are still five monkeys in the cage, but none of them have ever been sprayed by the hose, and none of them are attempting to get the banana hanging from the ceiling.

When another new monkey is introduced to the cage and is prevented from attempting to reach the banana heā€™s confused, and he asks the existing monkeys why they beat him when he tries. The other four monkeys shrug their shoulders.

ā€œDonā€™t know, but thatā€™s the way we do things around here.ā€

You may be able to draw parallels between this and process improvement initiatives youā€™ve attempted to run. I certainly can. This parable illustrates one of what I believe are the two most poisonous BPR dangers, and Iā€™ll be writing more about them both in the not too distant future.

Watch this space!

Blog

New Home Server Setup

As I mentioned briefly in a previous post, my home server is in desperate need of an update. Last weekend I took the plunge and bought the hardware necessary to build a replacement.

I donā€™t need anything especially powerful ā€“ the chief function of this device is as network-attached storage ā€“ but I do want room to grow and do things with this new server that werenā€™t possible with the hacked pogoplug device I was using previously.

image

I bought a Celeron-powered Intel NUC, a 750gb harddrive, 8gb of RAM and an 8gb USB drive. My intent was to use the 8gb drive as the boot device, keeping the harddrive entirely free for storage purposes.

I chose the Intel NUC primarily because of its small size and low power consumption (it uses a particularly small amount of electricity with the Celeron processor in the model I opted for). Iā€™m a big fan of this platform though, and when the time comes to replace the media-centre PC that lives underneath the TV in our living room I will probably buy another one of these. That said, the platform is not not without its problems. Read on, to learn how I set mine up.

Hardware Installation

First things first is hardware installation, and this was especially simple. You remove four screws from the base of the computer and the lid slides off. Inside youā€™ll find a metal chassis for the 2.5ā€ HDD, and you lift that out to revel the motherboard.

image

In my model of NUC thereā€™s a single SODIMM slot for the RAM, so I slotted that in. Next up is the HDD itself. The chassis includes brackets to hold the drive in place and the power and data connectors are already positioned. The drive just slots in, and you insert a couple of screws to hold it in place.

image

And thatā€™s really all there is to it! You put the cover back on, and tighten the four screws on the base of the unit. Done.

BIOS Update

The first thing to do is update the systemā€™s BIOS, and this really is an essential step. This thing comes with Intelā€™s visual BIOS, and the version it ships with has some issues.

image

Updating isnā€™t difficult: Head on over to Intelā€™s website, download the latest firmware and put it on a USB drive, boot into the BIOS and hit F7.

Even with the latest version installed, the BIOS is where this thing falls down, in my opinion. If youā€™re planning on installing Windows 7 or 8 on this thing then you probably wonā€™t run into any problems. My plan was to install an alternate OS though, and I ran into a whole bunch of issues. I believe this was because of bugs in the BIOS and its implementation of EFI, but I donā€™t know enough to say this for sure.

Software Installation

My plan was to install vSphere Hypervisor and use this thing to host a couple of virtual servers. vSphere has a hardware compatibility list and none of my hardware is on it, but Iā€™d done some reading and learned that I could slipstream drivers for the HDD and network card into the install. Nevertheless, I never did manage to install vSphere ā€“ the install just froze every time and I couldnā€™t get through it no matter what I tried.

The next hypervisor I tried was Proxmox VE. The install completed just fine, but I couldnā€™t get the server to boot. While the problems I had with vSphere may well have been in relation to my use of unsupported hardware, I firmly believe my problems installing Proxmox were related to the BIOS, or at least an incompatibility between the EFI implementation in Proxmoxā€™s version of the Linux kernel and the BIOSā€™ EFI implementation. I never did manage to get this working either, except for briefly with a cludgy workaround involving booting from a live-CD and entering the relevant commands to make GRUB boot the OS installed on the HDD instead.

After a day of frustration and failed attempts to install an OS, I moved on to my third VM hypervisor, oVirt. With vSphereā€™s proprietary solution the OS and the hypervisor are closely intertwined. Itā€™s possible to install Proxmox on top of an existing Debian install, but itā€™s not the recommended way of doing things and the process seems complex. oVirt, by contrast, seems to have been designed to be installed on top of an installation of CentOS. An all-in-one install image is offered, but after the previous dayā€™s failures I didnā€™t even bother with this ā€“ I did a (successful!) minimal install of CentOS and then used the yum package manager to add oVirt on top.

With the hypervisor up and running, I used the web-interface to install Ubuntu Server into one VM and Windows Server 2008 into another. I plan on adding two more virtual machines, one Linux and one Windows, for testing and playing around.

image

Blog

Kaizen Widsom

See, I do have my occasional moments of profanity profoundness!

We were talking yesterday morning about an upcoming Kaizen event that one of my colleagues will be running as part of a process improvement initiative that she’s spearheading. Apparently there’s a whole blame game thing going on between the groups that participate in the process over why it’s broken, and she’s concerned this might influence the way her event unfolds.

This was my advice: Acknowledge in the introduction that there are issues, but affirm that everyone in the room owns the whole process (even though they may only be a subject matter expert for a part of it). Recognize that all the participants are there because they see there’s a problem, but certainly not because they are the problem. Quite the opposite, in fact.