Real Life Business Debacle Highlights Importance Of BPM System Robustness

On his ebizQ blog, Peter Schooff, based on a posting in the the MWD Blog, asked for a definition of  systems robustness.  (July 2012): "What makes a business process robust?"  The question of robustness is much more important than you might expect.  The definition of robustness gets to the heart of what it means to build successful systems for business.  Addressing the question of robustness is one antidote to the "magical thinking" which is sometimes found in the executive suite.  But to think about robustness, one must have an understanding of the technical meaning of the term.  The term is sometimes bandied about along with other feel-nice business jargon, including the word "agile", with the result that the word loses it's power and your dialogue is robbed of meaning.  Here are your host's comments, mirrored from ebizQ:

In the context of several recent banking debacles, a question on the definition of system robustness is a good question. It's a good question because at least one of the UK banking failures appear to have happen at the intersection of technology, business process outsourcing and business process management. The failure was very high profile because thousands of customers were reported to have been locked out of their accounts for extended periods of time.   (This failure was not the same issue which was the trigger for the ebizQ thread; however interestingly, both issues conceivably involve business process.)

Why is "robustness" a good question in the circumstances? Because the ostensible failure of consumer banking services could correctly be characterized as a situation where the system "lacked robustness under conditions of outsourcing." The statement "conditions of outsourcing" gets to the formal definition of robustness.

It's worthwhile then summarizing a formal definition of robustness, which will be an elaboration on Scott Menter's good item on ebizQ. A system is robust if system states and outputs vary proportionally with the violation of system assumptions. In other words, when the unexpected happens, a robust system should perform reasonably well, as long as unexpected events are not too crazy. What we don't want is an unexpected environmental condition, which although minor in itself, causes a wildly disproportional change in system state and output. In a well-designed system, characterized by robustness, small violations in environmental assumptions should cause reasonably small, perhaps manageable changes in state and output.  You could say colloquially that "the punishment fits the crime", where the failure of robust systems are concerned.

All well and good you say, we'd all like to have robust systems, but gosh darn it all, isn't that what we pay the outsourcing company for?

For the case in hand (although this is only speculation) this sort of "throw all responsibility on the outsourcer" approach might have been the problem.  This is the problem of "magical thinking". Because when an organization takes responsibility for building a system, it is always the case that you can never model all environmental states in which your system will operate. Modelling everything is both technically impossible as well as financially infeasible.  You cannot avoid your responsibility.

Therefore, given that all systems are constructed in circumstances where assumptions are guaranteed to be violated, the question of robustness is a question for any system sponsor, from the get-go. How much are you prepared to invest in modelling and researching your environment, in support of minimizing your risk? And how much are your prepared to invest in software construction which has the characteristic of robustness?

And finally, what then is the performance of robust software under conditions of unplanned environmental events? We have said above that the software should react "proportionally". If someone in an BPO situation runs an overnight account updating job incorrectly, this error should not result in a lock-out of thousands of account holders, with the attendant bad publicity. Running a bad job, which violates the assumption that humans will do their jobs correctly, should only require that the job be re-run, and perhaps some proportional remediation.

 The field of BPM is enhanced when we make the effort to clearly define the terms. System robustness is critically important and should be a key agenda item during planning for any new system.

Top 10 Reasons Not To Hire Competent People

Popular author, columnist and headhunter Lou Adler has written an item (June 2013) with the provocative title "Top 10 Reasons Not To Hire Competent People".  The meat of the article concerns the subhead: 

"The number one reason not to hire someone who is competent is lack of motivation to do the actual work required."

The underlined phrase is the key here, and concerns the responsibility of management to concern itself with the "actual work" required for a given function.  The appearance of this comment by a leading practitioner in management labor markets is a signal about changing management practices -- at least for those practices at organizations that will survive.  Mr. Adler's focus is on an extensive (and important) set of management skills; he also identifies the specific technical competence that is at the core of any role.  It is this technical competence that he is warning against -- because if technical competence is a proxy for ignoring the critical importance of general work and management skills, the new hire will not likely be successful.

How is Mr. Adler's insight related to the question of magical thinking and work?  

The relationship is that the flawed hiring process described by Mr. Adler is a hiring process characterized by magical thinking.  

To use "technical competence" as a proxy for the eventual success of the hire is to ignore one's responsibilities to understand the work to be done.  

Technical competence is just one requirement for success.  The other factors identified by Mr. Adler (and a thousand other management writers) are as important.  Traditional technical hiring focuses on technical competence as a proxy, and that concern with technicall skills is probably the last that time that the organization will look inside the black box of work.  

Adler proposes that the hiring process -- in the words of your host -- "open up the black box of work" and look at the entire suite of requirements for success.  That means understanding the work -- and avoiding magical thinking.

Here is the original reference on LinkedIn: