Declan Chellar

A visitor to my blog commented on the post “No favourites” saying that her solution to the problem of being asked multiple security questions (none of which might apply) is to use a single word as the answer to all such questions.

So no matter whether they ask what your favourite movie is, or what your least favourite infectious disease is, or who you would most like to come back as if reincarnation were possible and you were run over by split-level sheep transporter, your answer might be “Rumplestiltskin”.

As with many elegant solutions, it is very simple.

Of course, the effect is to reduce all security questions down to one:

“What is your backup password?”

That’s right, all that time trying to come up with clever questions… wasted.

I’m not convinced that asking a bunch of questions to which the user might not be able to relate (or the answers to which might change over time) is the best solution, especially if it leads users to effectively using a backup password.

It makes me wonder whether the requirement was expressed along the following lines:

When a user forgets their password and has to ask for a reminder, we need to be able to ask security questions.

A poor requirements analyst would simply document the requirement as stated, then ask what the security questions should be and hand over the requirement and the list of questions to a developer. I call such people “requirements stenographers” and they are about as useful as a tape recorder but a lot more expensive. Chances are that a developer will simply build what was asked for, rather than questioning the requriement, especially if development is being done off-shore. GIGO.

An analyst, on the other hand, always asks why and by encouraging and helping the customer to find the right words to explain why, something along the following lines might be discovered and documented:

When a user forgets their password and has to ask for a reminder, we need to confirm the identity of the user.

Thus, a good analyst drives down to the real business need and expresses that need in a way that allows the maximum flexibility in producing both business and technical solutions.

To the people who think up security questions for web sites:

I do not have a favourite actor / musician / artist. If I pick one just for the sake of it, I will not remember my choice when I have to answer the security question.

I did not have a favourite place to visit as a child.

I do not have a favourite song and even if I did, it would probably have changed by the time I have to answer the security question.

Nor do I have a favourite book, even though I have an extensive library.

I don’t remember what was my most memorable gift as a child.

Nor do I remember my first toy animal.

I don’t follow sport, so I don’t have a favourite athlete.

I have never been married, so I don’t know the first and last name of the best man at my wedding.

In fairness, I do remember the name of the first company I worked for.

While I like food, I don’t have one particular favourite and even if I did, it might change before I ever needed to use answer a security question.

As for my dream occupation, it certainly is not thinking up security questions.

What I do remember, is my password! So please stop making it mandatory to select a security question!

Kind regards,

Declan Chellar

Out of curiosity, I have Wordled my curriculum vitae.

A former colleague posted that question in Facebook today.

My response was:

Because many people care more about leaving their stamp than about achieving the strategic goal. “I succeeded even though we failed” sounds better to such people than “We succeeded”.

This is also true on integration projects where there are multiple suppliers. When we work together so that the strategy succeeds, everyone succeeds.

E-V-E-R-Y-O-N-E

The ability to embrace change is a good thing, of course, but the desire to change things for the sake of it reflects insecurity,  a lack of understanding of how things really work and, perhaps, an excess of personal ambition.

The world, not just the business world, needs fewer such people now more than ever.

And I’ll say it again.

Spelling and punctuation are important. When you make mistakes, people tend to focus more on your lack of literacy than on your message.

Nobody cares what this guy's original message was.

Networking is important in business, but it amazes me how clumsy some people’s attempts at networking are.

Case 1
Not long ago a business contact of my wife’s asked if she could help her husband get work, as he had just lost his job. My wife put his CV (resumé) about and arranged some interviews for him. As a result, this fellow got a job.

As it happens, this business contact and her husband live in the same apartment block as us, but the husband never contacted my wife to thank her for helping him get a job. Not a card, not a phone-call. What’s more, whenever he sees us, he greets me, but not her. Maybe he doesn’t realise she is the woman who helped him, but if that is the case, it is because he never bothered to find out.

The other day, however, he popped in to my wife’s office and asked to see her. The receptionist called her and said that her neighbour had popped in to say “Hello”.  Of course, my wife had no idea who it was at first and when it dawned on her, she was not interested in seeing the fellow. When the receptionist told him that my wife was not available, he left a message to say that he had just joined such-and-such a company and that if my wife’s company ever needed their services, she was not to hesitate to contact him.

Recap: she gets him a job, he doesn’t thank her, he proceeds to ignore her, then he calls on her when he needs her.

That’s a very odd notion of networking.

Continue reading Networking: how not to do it

Jonathan Kupersmith has a great article over at the Business Analysis Times, titled: Business Analysts are Set-up to Fail

In my experience working for (and in partnership with) global companies, analysis is often done by teams consisting exclusively or mostly of junior analysts. I believe this is because in many organisations, analysis is seen as little more than stenography, so they put the cheapest people on the job – usually graduate trainees.

Hardly any of those junior analysts ever get full systems lifecycle experience, so they never learn to appreciate the perspective of the developer or the tester (see It’s about the software and The customer isn’t the only consumer).

I'm senior because I've outlasted the rest.

Most of them stick around for years, getting no further mentoring or training and end up as senior analysts because of their “years of experience” rather than any serious ability.

I once worked with a senior BA, with twenty-five years’ experience, whose idea of eliciting, documenting and analysing requirements was to copy and paste a set of meeting notes under each requirement Id. The worst thing about that was everyone else on the project assumed the way he did it was just the way requirements analysis was done, so never questioned WHY it was so poor. Flaws due to a lack of any actual analysis were fixed during UAT and that was just accepted as normal.

When I came along and suggested such things as visual modelling of flows and use cases and business rules catalogues and message catalogues and (most bizarrely of all) a requirements traceability matrix, I was seen as an upstart (until I proved myself).

What is the result? The BA Experience (as Kupe calls it) is poor for those who have to consume the output of junior BAs (junior in ability, not years). I think this is why so many developers think they could do as good a job as the BAs. They probably could!

Kind regards,

Declan Chellar

Business Process Modelling Notation (BPMN)  is the notation developed by the BPMN Working Group.

I have just updated the following series of posts to bring them into line with BPMN, although you will see that I have added some colour coding:

• Introduction to drawing workflows
• Process exercise

You can find a key to the elements on the BPMN Working Group website and the Visio stencil I used is here.

Kind regards,

Declan Chellar

As a business analyst, my job is largely to help a business define and document its needs, usually so that those needs can be satisfied by technology. However, if we assume that technology is always the answer, we might find ourselves overlooking other solutions that might satisfy the business needs more quickly and more cheaply, as this article from the BBC news website shows.

This will catch a lot of people by surprise in the business world, particularly the world in which I move, where cognitive skill (watch out for that phrase in the video) is key.