8 Useful Tips to Pick an Analyst

Type: Rules


Every now and then I run into the task to pick a business analyst or systems analyst for a project or customer. Sometimes this starts with writing a job offer, sometimes with a colleague asking if I could take part in a job interview with some prospect. What should you look for?

Rules and Notes

R1: Clarify what tasks the candidate will have. 'Ok, this is a no-brainer

R2: Clarify what the challenge in this particular project or this particular job will be.

R3: Clarify what (analyst-specific) professional skills will be needed, now, and in the future, in this particular job.

R4: Clarify what soft skills will be needed, now, and in the future, in this particular job.

R5: Make sure the candidate knows these things (and has a sound approach to dealing with them):

  • Stakeholders seem to change their mind on a regular basis. 'I think they don't, it just looks like a change
  • Goals are seldom properly understood.
  • Demand and Supply speak two different sociolects.
  • Stakeholders (among other people…) have trouble communicating about future, i.e. the benefits, or the system-to-be.
  • Other team members, including fellow analysts, architects, and QA-folk, deserve proper appreciation.
  • A problem is a solution to a problem is a solution to… (also see the means-and-ands post)
  • Many people (the prospect, too? Would be a bad sign for an analyst.) have a well developed answer reflex, so finding out what the problem really is can be quite a challenge.
  • Any required product quality can be described in a meaningful, quantified way. (Refer to Tom Gilb's extensive and highly useful wokr on the subject.)

R6: Clarify what testing skills will be needed. 'An analyst that does not know how to design acceptance criteria?

R7: Look for someone who uses words like 'now and then', 'generally', 'frequently', 'some', 'somewhat', 'arguable', 'among other', 'on the other hand', 'also', 'able', 'allow'.

Note: The language gives you hints on the prospect's experience level. Experts tend to have many answers.

R8: Avoid people who use words like 'steady', 'always', 'every', 'all', 'absolute', 'totally', 'without doubt', 'nothing', 'only', 'entirely', 'without exception', 'must', 'have to'.

Costs, Savings

<Would be great. What does it take to implement those rules? What does it give?>

Side effects

<Is there anything that happend or will happen as one implements the rules? This relates to both wanted and unwanted effects ('unwanted' does not imply 'negative').>


"Excellence is the driver for software development, not uniformity." — C.C. Shelley

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License