Hands up anyone who has been invited to a meeting, spent an hour or more listening to someone drone on (or worse, sat through Death by Powerpoint), only to wonder why you had been invited in the first place. Oh, look! All of you.
MS Outlook allows you to indicate whether each attendee is required or optional but no more than that.
So here is a suggestion: in the body of the e-mail, list all the required people and after each name, state why that person is required. This, to me, is basic business courtesy.
Hint: either you need them to contribute something or you need them to learn something. If it’s neither of those, they are not required!
Now I can hear some people saying, “I’m too busy to put all that information into a meeting invitation!”
 In other words, you’d rather save yourself five minutes than save the project several man-hours? Now, that’s team thinking.
Let’s flip it on its head. You have a right to know why you are required at a meeting. If you get an invitation that doesn’t make it clear, reply and ask the organiser to make it clear. Expect the organiser to make it clear and if it is not made clear, decline the invitation. If that doesn’t provoke a response, then you weren’t really required, were you?
If declining does provoke a response, then ask again why you are required.
But after all that you find yourself in a meeting and you realise it’s a waste of your time. You aren’t learning anything and you aren’t contributing. When that happens to me, I wait for the next break and politely explain to the host that there is no point in my being there. Then I get back to work.
Takeaway:
- Your time costs your company and your customer money. People will inadvertently waste that time and money by inviting you to meetings which you do not need to attend. Make sure you are really needed at each meeting.
Kind regards,
Declan Chellar
Many of you reading this will not know that in addition to being a business analyst, I am also an aspiring writer.
On a recent business trip, I began writing a log of my journey, as it turned out to be not as straightforward as I would have liked. I had intended to publish the log here, as I imagine a lot of you would be able to relate to it.
However, the log turned into a story of sorts. I ended up weaving elements of my inbound flights to Dresden and my return trip, as well as a walk I took around the city. Most of what you are about to read is true. I hope you can tell which part is fiction!
Kind regards,
Declan Chellar
Continue reading Business trip
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:
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
|
|