Human Nature Resilient Processes

The tsunami induced nuclear crisis in Japan is rightfully scaring the bejeezus out of everyone who is paying attention... How on earth could a system with such potential for devastation have relied on such a fragile process for disaster recovery?

Japan's nuclear power plants relied on external power in order to shut down safely. No external power, no safe shutdown.  I'm sure that someone who analyzed this process "computed the odds" and determined that the likelihood of external power loss occurring at the same time that a plant shutdown was required was incredibly low - virtually impossible - nothing to worry about.

Well... They must have missed a decimal point or something, because the unlikely happened.

As the renowned Murphy's experiences would remind us, unlikely things happen all the time... or more precisely... things that we judge to be unlikely happen all the time.

Are these process failures really unlikely, or are they an expression of the true nature of things?

Processes must take into consideration the environment in which they operate... and that environment always has at least two natures that must be addressed:

• Physical Reality - aka nature with a capital 'N'
• Social Reality - aka Human Nature

Japan's current nuclear problems might seem to be a clear case of not properly analyzing the physical reality of power plant near shoreline near ocean fault, but time after time we find that Human Nature screws up processes that should have worked. Somewhere in Japan's equation a human's judgment was influenced to overlook what's now obvious.

Human's are motivated by the darnedest things...  and one of those things is economics.  I would have said greed, but that would be unfair.  Humans, and by extension their companies, are motivated by profit and loss.  Potential gain versus potential pain is a major driving force in all of our endeavors.

Years ago I worked for a company that built safety systems for power plants that use coal, gas or oil to generate steam.  The process by which these plants operate is conceptually simple - burn fuel to generate heat, and use that heat to boil water, and use the steam from the boiling water to spin a turbine that generates electricity.  The not-so-simple part of this process is to burn the fuel as quickly as possible so that you can generate a lot of electricity.  You have to maintain just the right ratio of fuel and air at all times, so you're constantly pumping both fuel and air into your furnace.  It's actually a controlled explosion.

If something goes wrong and your flame goes out, you need to shut down the fuel and air flow as quickly as you can.  If there's a lot of hot unburned fuel and air in your furnace and you get a spark you are very likely to hear a very loud boom (the least of your worries when your power plant explodes).

To avoid explosions, companies like the one that I worked for built systems that monitor the flames and shut down the fuel and air flow when a problem is detected.  Interestingly enough, the impetus for installing these systems usually came from Insurance Companies rather than from the plant operators.  Most plant operators trusted their workers to manage the burners... most insurance companies didn't.

Let me add here that it's very expensive to shut down and restart a power plant.
You can't just flick a switch... and it can take hours to restore service.  Hours of lost revenue and additional expense.  Consequently, if a "safety" system shuts down your plant in error, the plant operators get very upset.

One of my coworkers, Ben, told me a story... I have no evidence to support this story, but it's reasonable to believe that it's true...

One day Ben happened to be sitting in the control room of a power plant when our safety system detected a problem.  The alarms went off, and Ben could hear the mechanical relays that would close the valves start "clacking".  The safety system was doing everything that it could to shut down the plant, but nothing happened.

Meanwhile, the control room operators took steps to resolve the problem.  I don't know what they did, but the plant kept running and nothing went boom.

Perplexed, Ben started poking around, and lo and behold it turned out that the safety system was not connected to the valves that it was supposed to close.  Perhaps it had never been connected, perhaps it had been disconnected... the end result was the same.  No safety system.

Of course the control room operators were pretty smug about this... They'd fixed the problem, there was no boom, and most importantly there had been no loss of revenue.

Human nature broke this safety process.  The motivation to "keep it running" was far more compelling than the motivation to "stay safe".

Humans will always take risks.  If your process is not resilient enough to survive these risks, then it's going to break.

I believe that nuclear power is key to our future... and new designs that rely on Physics can produce much safer plants... but if we don't also address Human Nature it's just a matter of time before we hear that very loud boom again.

Power to the People - to Program

Today I read a fantastic interview with Irene Greif on The Psychology of Collaboration.  I highly recommend that you read this article and draw from it your own conclusions, but I am particularly drawn to the following statement:

"I think it is not about the technology per se, but more about finding technologies that are resilient against controls [by management]. When I first came to Lotus, I was excited [that] anybody could create a Notes database on a server and set up access control in a very intuitive way. Anyone, not a database administrator, could create a place to meet. Slowly, over time, [IT managers demanded more control]. You would have to submit a request to create a database; you would have to submit a request to change access control. As a result, a lot of places [that use Notes] don't have the "group experience" in Notes, and they just use it for e-mail."

Software that had been intended for the masses was slowly subverted by the managers... to the point where what had been organically adopted became institutionally worthless.  I'd be stunned, but unfortunately the story is all too familiar.

For the past few years, I've been helping teams implement Managed Business Processes using the Lombardi BPM suite that was acquired by IBM last year (Fortunately, IBM acquired me too).  My primary job has been to enable the new owners of our BPM suite to take full advantage of their purchase - and to do that I coach small teams through the implementation of their first managed business process.

When IBM announced that it would acquire Lombardi in late 2009, Lombardi's suite was described as a Departmental BPM Suite.  Some folks were upset about that, but it didn't bother me at all.  I've found that the best way for a company to benefit from BPM is to start small, achieve an "early win", and then build on that success. Starting with a "Departmental BPM Suite" sounds like a great idea to me.

The great thing about working with a team on a departmental BPM solution is the spirit of ownership.  The folks on the implementation team are almost all very passionate about the process we're working on.  They live and breathe with the process, so they are tremendously motivated to get the solution built and to get the solution deployed - very quickly.

These experiences with "Departmental BPM" are what make Irene's recollections of Notes' Databases resonate so strongly with me.  The ability for a small team to develop and deploy a focussed solution is a very powerful thing... and immensely valuable for the business.  It's a fantastic "group experience".

But just like Notes' Databases, there comes a time when the ability for "anyone" to develop and deploy a managed business process begins to raise "red flags" for those who have to manage the enterprise as a whole.  As BPM spreads through the enterprise, the natural tendency to want to control that spread takes hold.

I've experienced this first hand... Early successes with BPM, run as small agile projects, attract the attention of enterprise level architects and program managers, who react with horror at the anarchy and call a halt until control can be re-imposed.

I am not at all suggesting that the concerns of the enterprise-level folks are invalid - In fact they're quite valid - it's just sad that these legitimate efforts to regain control sometimes end up stifling adoption.  The result is often the same as Irene describes with Notes - the true power of BPM and Notes is never realized due to the inability of those systems to be resilient in the face of the controls that management must place on the software.

Anarchy is not a good thing... but empowering the masses to build their own solutions is a great thing.  That's where I think Irene is really on to something when she says she's seeking out software that is "resilient against controls"... I don't for a moment think she's suggesting that controls are bad. I think she's saying that we have to figure out how to write software that preserves the user's freedoms in the face of the controls that management has to impose.

Very difficult challenge... but the people are worth it: Power to the People - to Program!

Business Management Rules and Processes

I am a Process Guy - When you ask me how to better manage your business, I am going to suggest that we take a look at your business processes to see if we can improve them by using software to manage those processes.

Many colleagues of mine are Rules Guys (and Gals) - When you ask them how to better manage your business they are likely to suggest that you take a look at the decisions that you must make to manage your business, and identify any of the rules that drive those decisions which could be automated to reduce your burden.

Processes almost always include decisions that guide the specific activities that are performed (or who performs them)... and the rules that govern your business often instigate a new process or influence the execution of a running process.  You really never have one without the other.

If you need to manage your business, then you need to take a good look at both your processes and your rules.

Tips for the Business Process Developer - Human Interfaces to Business Processes

I've probably mentioned before that there's anecdotal "evidence" that when implementing a Managed Business Process folks will spend about 80% of their time building the human interfaces to the process.  That sounds like a very bad thing, but in reality it's just a testament to how good the BPM Suites are at building the Process Choreography and Orchestration pieces.

Given that building your human interfaces is going to consume a big chunk of your development effort, it's helpful to step back and consider just what sorts of human interfaces a business process needs.

Task Notification Interfaces
Folks can't be expected to complete their tasks unless they know that they have tasks that they need to complete.

In many cases you will want to send email to a participant to notify them that they have work to do.  That's actually a very good approach when you have a participant who only does work for you infrequently.  Checking email is something that folks do all the time, so an email notification that there's work to do will probably get noticed.
Email notification isn't a good approach if the participant frequently has lots of tasks to do.  Their email inbox will quickly become overloaded, and they'll have difficulty keeping track of the work that they are supposed to do.

For participants who frequently have a lot of tasks to perform, you'll want to build some flavor of a "To Do List" interface.

"To Do List" interfaces have three goals:

• Make sure the participant knows what tasks they are responsible for
• Make sure the participant knows when each task is due
• Help the participant prioritize which task to work on next

That last bullet is (of course) the hard one to implement.  A specific task may be very important to the completion of a specific process - But that specific process may be far less important than another specific process.  Often times the participant will need to consult Process Status information (see below) in order to determine which task they really ought to work on next.

Task Completion Interfaces
Folks can't complete their tasks unless you provide them with interfaces that let them do their work.

I've blogged a lot over the years about implementing Human Powered Services - probably because I've met a lot of folks who haven't thought enough about how to effectively build them.  I'll ask you to Google for my past blogs on the subject and just warn you that you can waste a heck of a lot of time on these interfaces if you don't concentrate on providing only the functionality that's absolutely required.

Process Status Interfaces
It's good to know the state of a process - Knowing what tasks have been accomplished and what tasks are left to be performed can be very helpful information.

Improved process visibility is one of the key promises of BPM, so think these screens through very carefully.  If you don't do them well, then you probably won't meet your BPM objective.

You will often build Process Status Interfaces for the folks that "own" some operational aspect of the process.
For example, if a supervisor is responsible for the completion of specific processes, then that supervisor will want a "dashboard" that presents the current status of all the running processes.  The supervisor will be particularly interested in any processes that are "at risk" - those processes that may not complete "on time".

When you build a process status interface, you will almost always incorporate functionality that will allow the user to "do something" to influence the running processes.  For example, if the user can see that a specific process is "at risk", they may need to initiate an escalation process or reassign some of the tasks to other participants.

Process Status Interfaces have the following purpose:

• Display the current status of the running processes that are of interest to the user.
• Clearly identify any processes that are "at risk"
• Provide interfaces for the user to intercede in any process that is "at risk"

Optionally, a process status interface may also provide a estimates on when specific process instances may be completed.  These estimates are based on the remaining tasks that must be performed and estimates for how long each task is expected to take.  For more accurate estimates, historical information about the past performance of the process can be used.

Participant Workload Interfaces

Participant workoad interfaces are closely related to the process status interfaces that I've just described... but they focus on the workload for each participant rather than on the status of specific running processes.

If you are a manager who is responsible for assigning work, then it's very important for you to know what everyone is already working on.  An interface that shows the user "who is working on what" is very important when new work must be assigned, or when uncompleted work has to be reassigned.

In a sense, these workload screens are a roll-up of the Task Notification "To Do List" interfaces I mentioned earlier, but they're meant for the supervisors rather than the workers.

Process History Interfaces
Being able to review the history of a process is key if you want to know whether or not the process has been running smoothly.

As mentioned before, improved process visibility is a key goal of BPM, and visibility into how well (or how poorly) instances of the process ran in the past is crucial.  Without this information you can't really hope to improve the process in the future.

Process history interfaces are essentially reports - and it's should come as no surprise that you may need to produce many reports for each type of process.  These reports are usually cumulative - What were the average execution times for the process?  Once norms have been established, then seek out the "unusual" process runs and try to figure out why those instances were outside the norm.

Given the nature of reporting, count on generating a lot of process history interfaces for a lot of audiences.  It's really hard to anticipate all of the reports the business may want, but start with the most obvious and insure that you're capturing all the data that's necessary to generate those reports.

If you're stumped on what "the most obvious reports" are for a process, then start by considering what you need to "remember" from the Process Status and Participant Workload interfaces that I described.  If a supervisor ever has to intercede in a specific process - by reassigning tasks or initiating an escalation procedure - then you probably need to remember "why" they needed to intercede.  As the saying goes, "Those who forget the past are doomed to repeat it".

Business Process Interface Snippets
Perhaps I've left out some aspect of Human Interface that your Business Process will need - but I think you will find that most of the interfaces that you need will fall into one of the categories that I've described.  Thoughtfully consider the interface functionality that you really need, and I think that you will find it a lot easier to build out your user interfaces.

My final offering is this: Don't confuse the human interfaces that I have described with specific screens.
Many of the human interface aspects that I have described will routinely be combined together on a single screen, or you will find a need to incorporate an aspect of a Business Process on an existing screen.

Consider building out each "aspect" of your Business Process Interface as a "snippet" or "panel", and you'll find it much easier to tailor your interfaces for each of the audiences that you need to serve.

---

Here are some closely related postings for those of you who may want to delve deeper:

• The Task Completion UI Building Process
• Building Functional Task UIs