Data quality issues for Business Analysts Association of Ireland

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.

Data quality issue for the Business Analysts Association of Ireland

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.

It's only fair to share...Share on FacebookEmail this to someoneShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page
0

A customer walks into a bar

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.

A customer walks into a bar.

It's only fair to share...Share on FacebookEmail this to someoneShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page
0

Understanding systems availability

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:

Systems Availability Tweet from John Arundel, @bitfield

It's only fair to share...Share on FacebookEmail this to someoneShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page
0

Postmortem reviews – “root cause seduction”

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.

It's only fair to share...Share on FacebookEmail this to someoneShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page
0

Can you still be “adopting” something 2 years in a row?

AIB_adoption_of_social_media

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.

definition_of_adoption

And no, I did think of that as well, but AIB weren’t actually a sponsor for the awards.

It's only fair to share...Share on FacebookEmail this to someoneShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page
0

Human vs systems error – the Dekker view

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.

It's only fair to share...Share on FacebookEmail this to someoneShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page
0

Weird data organisation at the Private Security Authority

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.

private_security_authority_contact_page

It's only fair to share...Share on FacebookEmail this to someoneShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page
0

Asking “how” and getting the right answer

This article, “The infinite hows”, is on the O’Reilly website and intended to be a critique of what is a standard Business Analysis method – the 5 whys.

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.”

 

It's only fair to share...Share on FacebookEmail this to someoneShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page
0

Powered by WordPress. Designed by WooThemes

shopify
stats