It is better to be silent and thought a fool, than to speak and remove all doubt.
I received their regular newsletter recently – even though I’d unsubscribed after the previous newsletter. Maybe that’s why the e-mail was addressed to me as follows.
Either way, pretty bad that they’d address an e-mail in this way to someone that is a member of the association, and worse that they’d ignore requests to be taken off their mailing list.
In my job, you’d either substitute the barman for the business analyst on a project, or the developers. As someone who’s the face normally of delivering functionality to the customer, it’s more likely you’d sub in the business analyst unfortunately.
This was my job for a long number of years – specifically putting in a monitoring process to publicise systems availability.Given my experiences there, I definitely can’t argue with this:
I promise that this will be my last reference to this article, “The infinite hows”, that is on the O’Reilly website. My last quote refers again to the investigations carried out after things go wrong – sometimes called postmortems in the IT world. I’ve written before here how people only really get the answers they want to hear when investigating why shoddy IT happens.
This last quote is attributed to John Carroll (Carroll, 1995), and describes what is called the “root cause seduction”:
The identification of a root cause means that the analysis has found the source of the event and so everyone can focus on fixing the problem. This satisfies people’s need to avoid ambiguous situations in which one lacks essential information to make a decision (Frisch & Baron, 1988) or experiences a salient knowledge gap (Loewenstein, 1993). The seductiveness of singular root causes may also feed into, and be supported by, the general tendency to be overconfident about how much we know (Fischhoff, Slovic,& Lichtenstein, 1977).
I would change that a little. rather than getting everyone to “focus on fixing the problem”, it’s my experience that people are focused on fixing a problem – something that can be loosely attributed to the IT issue that occurred, but it may not always necessarily be the actual reason for the issue occurring – merely the most palatable problem that can be acknowledged and easily resolved.
The tweet above from AIB Customer Service confused me back in November. Okay, so nice one on winning “Best Adoption of Social Media” award.
But hang on? For the 2nd year? Surely, in the second year that you’re using social media now, you’re now not adopting – you’ve done that already last year.
And no, I did think of that as well, but AIB weren’t actually a sponsor for the awards.
Click on the image for a larger version to read the rest of the detail.
In this blog post last week, I referenced the book The Field Guide to Understanding Human Error by Dekker, Sidney 2nd edition (2006) as quoted in this article, “The infinite hows”, on the O’Reilly website.
The other direct quote from Dekker in this article references a key question I’m interested in on this blog, whether a failure – in this case a computer or IT failure, can be blamed on systems or human error:
Was the accident caused by mechanical failure or by human error? It is a stock question in the immediate aftermath of a mishap. Indeed, it seems such a simple, innocent question.
To many it is a normal question to ask: If you have had an accident, it makes sense to find out what broke.
The question, however, embodies a particular understanding of how accidents occur, and it risks confining our causal analysis to that understanding. It lodges us into a fixed interpretative repertoire. Escaping from this repertoire may be difficult. It sets out the questions we ask, provides the leads we pursue and the clues we examine, and determines the conclusions we will eventually draw.
When it comes to questions like this, I’m always reminded of something a manager of mine once said – when discussing business analysis and requirements gathering, but also relevant to this discussion, I think:
It’s a computer – it’ll do whatever it is you tell it to do.
Or, the corrollary when it comes to identifying why something went wrong during a computer glitch – a computer will do anything that you (intentionally or otherwise) will allow it to do as well.
The Private Security Authority in Ireland is the statutory body with responsibility for licensing and regulating the private security industry in Ireland. one of the responsibilities of this Authority is to maintain a register that contains details of all individuals who have been issued with a licence by the Authority – a licence entitles the holder to engage in employment in different stated categories within the private security industry.
So, we’ve got a listing / database of peoples names. Standard practice – organise these peoples names by last name, then first name. So what’s the Private Security Authority method for organising their listing of licenced peoples names? First name, then last name.
Yes, seriously. Here’s a link to the listing of licenced individuals (amongst others – click the relevant link), sorted by first name, then last name. That’s 1225 pages of peoples names, organised by first name, then last name. Oh, and no unique reference number for each person on the list. And no page numbers.
You’d almost think they didn’t want people to find anyone on the list.
And no, that data isn’t organised that way by mistake. Even the internal staff within the Authority are organised according to first name first, then last name. This is the information from their “Contact” page.
While it’s quite an interesting article, and has somewhat caused me to adjust my own analysis approach by looking more at the “how”, rather than the “why”, this paragraph below struck me as extremely relevant when it comes to the topic of “postmortems”.
I’ve written about postmortems after a computer glitch occurs before on this site (here), and this quote from Nancy Leveson in her book Engineering a Safer World: Systems Thinking Applied to Safety (Engineering Systems) pretty much sums up my thoughts on how most computer glitch postmortems are carried out:
A final reason why a ‘root cause’ may be selected is that it is politically acceptable as the identified cause. Other events or explanations may be excluded or not examined in depth because they raise issues that are embarrassing to the organization or its contractors or are politically unacceptable.
A postmortem into an IT glitch is normally intended to discover what the reasons for the problem was. This could be an internal investigation, or as in the example of the Ulster Bank IT fiasco, could be something that has to be made public.
The follow up to a postmortem investigation is intended to be remediation tasks that are supposed to make things better. However, it may not always be the case that the real underlying causes for an issue can or would be addressed – i.e. poor management decisions, cost management and cutbacks, or anything else that could be embarrassing to management. In that situation, the direction of the postmortem can be easily manipulated to ensure that the root cause is something mainly benign and can be “addressed” through simple but ultimately pointless recommendations – improve training, ensure documentation in place, implement a checklist process.
Earlier in the article, two items are discussed that describe how postmortem investigations can be manipulated in this way – either intentionally or accidentally.These quotes relate more to accident investigations, but they are very relevant for investigations into IT or computer glitches:
“In accident investigation, as in most other human endeavors, we fall prey to the What-You-Look-For-Is-What-You-Find or WYLFIWYF principle. This is a simple recognition of the fact that assumptions about what we are going to see (What-You-Look-For), to a large extent will determine what we actually find (What-You-Find).” Erik Hollnagel, The ETTO Principle: Efficiency-Thoroughness Trade-Off
And this, from Sidney Dekker in The Field Guide to Understanding Human Error by Dekker, Sidney 2nd edition (2006)
“We think there is something like the cause of a mishap (sometimes we call it the root cause, or primary cause), and if we look in the rubble hard enough, we will find it there. The reality is that there is no such thing as the cause, or primary cause or root cause . Cause is something we construct, not find. And how we construct causes depends on the accident model that we believe in.”