Over the years I have been asked to participate in interviews where the candidate claimed to have analysis experience.
Sometimes the candidates were being interviewed for analysis roles, but often they were programming roles, but the candidate claimed to have significant analysis skills. My job was to test the validity of their claims.
My experience in interviewing almost a hundred programmers is that the vast majority who think they are analyst/programmers know so little about analysis that they could not answer the following simple question:
“What is the difference between analysis and design?”
Continue reading What’s the difference between analysis and design?
I was taken aback recently when someone told me they didn’t understand the concept of re-use.
You see, when I started out in software development, I was taught this concept, so I cannot imagine a world without it. Of course, I am not insensitive to other people’s situations, so I understand that if you have never worked any particular concept, you might have difficulty grasping it.
One example I saw involved a BA producing two process models for the exact same process, just because it was applicable to two business entities. On examining the process models, they were indeed identical, other than naming one “Open Account X” and the other “Open Account Y”.
I pointed out that it was the same process. The BA insisted they were not, but could not show any difference other than the process names.
Then the real challenge hit me: how do you explain re-use to someone who has never experienced it? It was so obvious to me that at first I could not figure out how to make it obvious to someone else.
Continue reading How do you explain re-use?
I have been reviewing CVs (resumés) for a client. The vacancy is for a Senior Business Analyst in the Pega domain. During the course of reading the CVs, I noticed that many of them, while they used the phrase “business analysis” throughout, had few or no examples of any tasks or achievements that would fall under that heading.
Having read all of them, I organised them into one of the following three piles (in descending order of interest to me):
- Clearly and accurately describes the activities of a senior BA. Worth interviewing.
- Describes the activities of a BA but without detail or clarity. May or may not properly understand the role of a BA. Certainly does not know how to express it in writing, so unlikely to be a decent senior. Worth an initial telephone interview to be sure.
- Has some core skill other than business analysis (e.g., project management or programming) and has attended some requirements workshops. The details provided in the CV do not support any claims to be a BA, never mind a senior one. Clearly does not understand what BAs really do. Not worth interviewing and wasted my time in getting me to read the CV in the first place.
Considering the waste of time involved in reading the category threes, it dawned on me that Wordle might have given me a strong clue as to whether a CV contained the right words to make it worth my while reading. At the very least, it might give me a sense of the order in which I wanted to read them.
Continue reading Using Wordle to filter CVs
Out of curiosity, I have Wordled my curriculum vitae.
Someone recently asked the following questions on the IIBA discussion forum on LinkedIn:
What recruitment procedure is to be followed to identify real BA competencies? Are 15 minutes presentation and 15 minutes group interview enough? Is there any best practice BA selection procedure?
For your consideration, here is the answer I posted:
I would say the first step is to have a job advertisement written by somebody who actually knows what the competencies are. I rarely see a job advert that lists hardcore BA skills and never see one that asks for certifications.
Secondly, I would put in place an interviewer who is an experienced senior BA – i.e., someone who knows which questions to ask and whether the candidate is giving a reasonable answer. Such a person would go prepared with a set of case studies and examples, as Kupe says [that’s Kupe Kupersmith – @Kupe on Twitter], and would know how to tailor the questions and tasks to the candidate’s stated experience.
I would start off with a simple question which (in my experience as an interviewer of analysts) eliminates 80% of the candidates immediately:
“In no more than 12 words, can you explain the difference between analysis and design?”
I can do this in six words, by the way.
Why does this question eliminate the vast majority of candidates? Because most people have no clue as to what analysis involves. Most candidates, hiring managers and recruitment agents think it means you can use Word and maybe Visio, you are experienced in attending meetings and you are not Hannibal Lecter.
I would then ask questions such as:
- What is a requirement?
- What is a business rule?
- What would you include in a requirements management plan?
- What would you include in a business case?
- Give me an example of a project you were on which failed due to analysis issues. Explain the issues and what steps you took to avoid them in subsequent projects.
- How would you go about performing a stakeholder analysis?
- At what point in a change initiative should data analysis begin?
If the candidate can answer such questions to my satisfaction, I will proceed with a case study which will require the candidate to use the white board. The case study would test, for example, the following (depending on the candidate’s stated experience):
- business process modelling
- logical data modelling
- candidate use case/user story identification
- activity diagram modelling
What are your thoughts?
Kind regards,
Declan Chellar
@AnalysisFu
Most of you who work in the world of software development are used to being contacted out of the blue by recruitment agencies.
I used to run a recruitment programme for a solutions provider, so I have dealt with agencies as a recruiter and as a job-seeker. Some are very good at what they do, others need some guidance as to how to behave. All are just people trying to get on in life. As a recruiter, I changed the way agencies dealt with me so that they had to work harder per candidate, but resulting in better filtering, so a higher success rate.
Most agencies, in my experience, rely too much on keyword searches and mailshots (or the on-line equivalent). As a result, they often target the wrong people, irritating candidates (by making them feel there is a chance of work when really there is none) and recruiters (by sending them CVs that have little relation to the job specifications).
So with apologies to William Bruce Cameron, here are my 8 Simple Rules for Recruitment Agencies:
- Don’t contact me unless you are already armed with a job description. I am fairly clever, so I know that when you don’t have a job description it is either because the job doesn’t exist and you are fishing for CVs (resumés) or you are not actually working on behalf of the client.
- Don’t contact me based on a keyword search. Actually read my CV or my LinkedIn profile. You’ll get paid a nice sum of money if I get hired, so earn it.
- Don’t send my CV to your customer without having studied it first and matched it against the “mandatory skills” in the job description. Your customer expects you to earn your fee. In return, your customer will like doing business with someone as professional as you.
- Learn what the words “mandatory” and “must” mean. If I don’t have all the mandatory skills you list in your job description, I will discount myself from the hiring process as soon as you contact me, so make sure they really are “mandatory” and not just “ideal”.
- Don’t contact me about a fictitious job just to get hold of my CV. I’m pretty intelligent and I know when you are faking it. If you just want my CV for your files, try asking for it.
- Don’t contact me about a job and then not reply to my reply.
- On LinkedIn groups, don’t fill the “Discussions” tab with job adverts. There is a “Jobs” tab for that purpose. Doing this makes you look lazy and unprofessional. Why would I want to do business with someone like that?
- When advertising a job online, mention the location in the headline (or even anywhere in the advert). Not everyone lives where you live, believe it or not.
You are business professionals, not pimps (despite what we freelancers might call you when you are out of earshot). Behave accordingly and freelancers and recruiters will recommend you to each other.
I guess there is really a ninth rule, which is that unless you can adhere to the eight rules listed above, don’t even contact me. I’m not that desperate for work.
Kind regards,
Declan Chellar
In this blog post I aim to provide an appraisal of the Pega Developer Network article “Getting Started with SmartBPM”, based on my experiences working on Pega projects in the field.
I am a certified Pega Business Architect and Methodology Black Belt, and here I provide an alternative to SmartBPM, which I hope addresses what I perceive to be the shortcomings of the methodology. This post addresses the SmartBPM methodology only and not the Pega Scrum methodology. Moreover, it does not address techniques specific to any discipline (e.g., use case modelling).
Note that Pega clearly states that the SmartBPM methodology “is not a concrete prescriptive process” , that it is adaptable and that the phase information is an outline only. Therefore some of my suggestions are nothing more than an adaption of the methodology and others merely add detail to what is currently in outline form. However, other suggestions are the result of the problems I see with the original PDN article or with the methodology itself. You can download the full appraisal in PDF form from the link below, but here are what I consider to be the critical flaws in SmartBPM.
Continue reading Review of Pegasystems’ SmartBPM
I am currently writing an appraisal of the Pega Developer Network article titled “Getting Started with SmartBPM”.
You can see the article itself on the PDN but you will probably need to use Internet Explorer.
I’m preparing the appraisal as a certified Pega Business Architect and Methodology Black Belt. An extract:
The author aims to provide an appraisal of the Pega Developer Network article “Getting Started with SmartBPM”, based on his experiences working on Pega projects in the field. Furthermore, the author will provide an alternative “Getting Started” guide, which will address any perceived shortcomings of the PDN article.
Note that Pega clearly states that the methodology is adaptable and that the phase information is an outline only, therefore some of the author’s suggestions are nothing more than an adaption and some are only a detailing of what is currently in outline form.
This is the layout I am planning to use for my alternative guide:
Watch this space.
Is “Business Analyst” a Job Role Facing Extinction? I keep seeing this question popping up on discussion forums and it is getting tiresome.
I find the question naïve and the following was my answer to a thread on LinkedIn today:
Business analysis is an essential skill in any change initiative. Firstly, you need to have a business model in place before you can even choose a technology. This work is done by dedicated business analysts. Even on Scrum projects, you cannot run sprints where there is no defined business model. When you get down to software development, if you are running a Scrum project where there is no BA role and software developers are collaborating directly with users in order to implement elements of the business model, all parties need to apply business analysis as a skill in order to ensure the business need is understood.
Developers who maintain a solution mindset when talking to the business will build the wrong solution because they will not have understood the need. Business analysis as a skill will always be needed on software development projects and the business analyst as a role will always be needed in defining business models.
Moreover, not all projects are suited to Scrum, I would say most would follow a risk-based RUP-type methodology, where there is a defined BA role.
Is the BA role becoming extinct? Far from it.
Even technology companies like Pegasystems who have traditionally championed developers’ talking directly to users without BAs in the middle are now acknowledging the need for Pega Business Architect. Why? Because it is all very well saying in theory that developers should be able to talk to the business in business terms, but in practice (in my experience), most developers find it very difficult to shake off the “solution mindset”. This is why even Pegasystems have defined the Pega Business Architect role (by which they mean business analysts, because the Pega BA does not get involved in the business architecture, but rather in requirements analysis).
Does that clear this question up now?
Kind regards,
Declan Chellar
You can now follow me on Twitter, if you have a mind to: @AnalysisFu.
I’ll be tweeting thoughts on analysis matters and linking to great articles written by people who matter in the world of business analysis.
Kind regards,
Declan Chellar
|
|