Saturday, October 3, 2015

Questions to ask at a requirements elicitation interview.

When I was an 18 year old trainee analyst I had to do my first requirements interview. I met with this old guy, who frankly would probably now be to me a young guy, in his office. “Tell me about your job” I said. “I’m like a mushroom” he said. “Kept in the dark and fed bull****”. I didn’t know what to say.
Don’t be caught out like I was. Here are some questions you need to ask when eliciting requirements by interview. Take a deep breath. Here goes:
  1. What is your current job title?
  2. Who do you report to line?
  3. Who do you report to functionally (dotted lines)?
  4. Briefly summarize your responsibilities.
  5. Do you have any accurate and up to date documentation that describes your responsibilities? If so, can I have a copy?
  6. What are the triggers that cause you to start the tasks for which you are responsible? Can I have copies of any associated documents, screens or reports?
  7. What do you do in each of these cases? What are the key steps you take? Who do you work with? What systems do you use? How do you know when you are done? What deliverables do you produce? Can I have copies?
  8. What works really well in your current job? Why?
  9. What works less well? Why?
  10. What happens when things go wrong?
  11. What happens when things go well?
  12. What suggestions do you have for improvements?
  13. What is your greatest challenge? How do you overcome that?
  14. If you could make just one change that will bring about significant improvements, what would it be and why?
  15. Can I have a copy of any remaining forms and documentation that you use?
  16. Can I have examples of any remaining system inputs and outputs that you use?
  17. Can I have a copy of your job description?
  18. Who reports to you? What are their titles and responsibilities? Can I have copies of their job descriptions?
  19. What training is required for your position?
  20. What training have you attended in the last two years?
  21. Who else should I speak with to obtain more information?
What do you ask? What are your favorite questions? What question do you most regret asking? Comment below!

Be professional and human: practice situational evolution!

As a practicing business analyst you are in a position of trust and privilege. You help organizations identify and solve business problems. You help to bring about change, and can have an impact on the lives of many employees, and the whole enterprise too. Professionalism is key; you want to be seen as an objective and trusted partner who gets things done. But if you remain aloof or detached you will undoubtedly miss opportunities to get the most value out of your stakeholders. So we practice situational evolution, so relationships start off on the right foot, and develop effectively.
So what is situational evolution and how do I do it?
It’s all about timing really. Imagine you are about to be interviewed about your current position by someone you don’t know (a business analyst). If that business analyst walks in and says “Hi, how you doin’? Went to a great party last night and boy am I hung over. OK let’s get down to it. Tell me about…”
Doesn’t create a good impression does it?
Consider a different situation. You have been working with business analysts on a project for six months full time. It’s the end of the project and one of the business analysts says “Our project is finished on time and on budget. I will see you at the presentation. Thank you for your exemplary efforts”. You ask the business analysts if they’d care to join your department for your next lunchtime pot luck, and you are told “thank you for the offer but we have work to do.”
You would probably be a bit hurt that your offer of friendship was rejected.
And that’s why we need to understand situational evolution.
At the start of a project, err on the side of formality. But as you get to know your stakeholder colleagues, start to drop some of the formality and interact with them in a lighter way. Now, care is required to time this correctly and not commit any social mistakes. And I would always recommend erring slightly on the professional side of things if there is any doubt. But your stakeholder relationships, and the quality of your work, will improve if you allow your relationship situation to evolve as you work together.
A major issue with this can be if you are working with a group of stakeholders with which you are very familiar, and where the situation has evolved to one where there is some joking and social activity. But then someone new joins the group. Remember that the new person’s situation is yet to evolve from the “professional” start point. So fall back to this until the new person “warms up”. It usually only takes a few days.
Have you ever been bitten by an error in situational evolution? Do tell – post a comment!

Just say “no” to requests for confidentiality.

When eliciting requirements you may sometimes be asked if you can be told something in confidence. There’s a great temptation to say “yes”. After all, you are a professional business analyst who can be trusted, right? But “yes’ is the wrong answer. Let’s see why.
You are in a somewhat privileged position when you are meeting with a stakeholder. It’s not often that an employee has a chance to provide facts, details and opinions about their work, and you are enabling that to happen. It will sometimes be the case that an employee will have something in mind that has never been shared, and perhaps they want to, but are fearful of doing so to their colleagues or managers. That fear may be real or not.
We want to avoid the observer effect; that is, where we measure something and measuring changes it. The professional business analyst wants facts, and also opinions, providing they are understood to be such. By taking on confidential information, whether accurate or inaccurate, real or perceived, we are in danger of allowing our elicitation process to change the environment. What expectation are we creating in the confider by allowing them to confide? And more important, what are we expected to do with the confidential information? We certainly can’t pass it on: it’s confidential!
A derivative of this is when you are told “this is confidential. You can pass it on but don’t attribute it to me”. All findings from elicitation must be reviewed and signed off by the providers of the information. This has to be done in writing. So you have to make a written record for validation, which thus becomes attributable (unless you try to keep everything anonymous. But anonymity betrays the value of the information elicited. And you can be sure it won’t stay anonymous for long!)
The bottom line: if asked if you can be told something in confidence say no. Otherwise you can end up making yourself the office gossip.
But can we do more than say no?
Of course! Encourage the would-have-been confider to bring the issue up to a supervisor or manager. A person in this role is the best person to deal with any confidential issues, and their reality (or otherwise). And get to know the current state of your domain well. Observe what really happens, and incorporate your observations in to your findings. These observations will mention situations and individuals. And that’s OK. You are not breaching any confidentialities.
So, do you agree? Are there any circumstances you have encountered where you have accepted confidential information? If so, what happened?

Business analysis myths.

  1. A business analysts can act as a proxy for a subject matter expert.
  2. A business analyst must have business knowledge of the enterprise in which the analyst is working.
  3. You can become a business analyst without formal training.
  4. Business analysts are not needed on agile / lean / … projects.
  5. Business analysis slows down projects.
  6. Working code is needed, not documentation.
  7. Upfront planning is not needed; architecture emerges.
  8. Subject matter experts must work with developers, not analysts.
  9. Modeling tools generate poor code, so don’t try to use analysis models (or any models) for this purpose.
  10. Software quality is a job for QA; requirements is a job for the business analyst.
Any more? Disagree? Post a comment!

Get better at buying stuff (Part 2).

If you haven’t read part 1 already I recommend you do so first!
So now we know we need to acquire something. And we know the relative importance of the features we need. What next?
There are lots of organizations out there clamoring to meet your needs. The key is to hook up with the right one. The key to success is to understand what you are really buying. Maybe it’s obvious. Maybe it’s not. Let’s think about it.
Say I’m buying a vacation. My needs for the vacation are focused on the vacation itself, with the hope of a great time and happy memories. The life of the product I am buying ends at the end of the vacation. Now say I am buying a washing machine. The feature themselves are really important, but the life of the washing machine is going to be longer than most people’s vacations. So over that life you are buying a relationship with the vendor from which you made the purchase, and to some extent, the original manufacturer of the washing machine. After all, you will usually need parts and repairs at some time. So see the acquisition as being not just the washing machine, but the relationships. It’s the same when buying new kitchen equipment, and a car, with each requiring progressively more rigor.
Now imagine needing to acquire something really important and / or complex. Say a brand new house. Or a computer system for a large enterprise. You know what is essential and important and you are ready to assess what is available. Unless you only intend to keep your house for a very short time, or if you are desperate for a house, then relationship with the vendor is really critical to manage the risks of your acquisition. You must realize you are buying a relationship as well as product. And further, you need to be very, very careful about customizing your acquisition. More on that later.
So with our essential, important and desirable features (that I will now call requirements) in hand, you can start on the acquisition process. In summary, what you need to do is find out what options are available in the market place, assess how well each option meets your requirements, and then decide on the option you prefer.
You’ll start by doing your research. At this stage you are not buying, all you are doing is seeking information. Use the Internet to obtain information, and be sure to consult independent reviews of the products. Obtain brochures. Visit the companies who supply the products you are interested in, but don’t reveal that you are buying (yet). Ask questions and assess the answers. Seek out anyone who already uses a product you are using and record their experiences and opinions. Write it all down. Ignore “buy this quick / special offer today only” unless you want to risk making a mistake or you are absolutely certain that all of your essential and many of your important requirements are being met at a realistic price from a vendor with which you are confident you can will have an excellent relationship. And even then, think twice at this stage.
When you have completed all your research, lay it all out and review it. Then look at your requirements and assess the extent to which each option meets your needs. An option is rejected if it doesn’t meet all your essentials. After that it is rejected if it does not meet any important requirements. Hopefully you have some options left! If not, you will have to either compromise on one or more of your essential requirements, or do more research.
Hopefully you have at least two options left. And no more than three. Now you can scrutinize the remainder to make your decision. Consider first the number of important requirements, and then the number of desirable requirements, that are met. And be sure to consider all of the relationship factors for important acquisitions.
Now let’s come back to customizations. Providing you don’t compromise the integrity of the original product, customizations can be ok. A different color on a car, a new type of entertainment system offered by the manufacturer, are all reasonable examples. But changing the engine to a new, third party product may not be the best idea, unless you really are looking for something special. Because if the engine is non-standard maybe the hood has to be non-standard, and that makes more work. And if you are in a wreck and the body gets damaged, getting the hood replaced will likely be problematic. If you are going to buy a standard product it is better to adapt your needs to the standard product, rather than having it tailored. And this is never more true than with computer systems. Never tailor the standard product, because computer systems (almost unique to computer systems products) can be upgraded (on some occasions they must be upgraded). And if you have moved from the standard there is a very high chance you won’t be able to upgrade. With computer systems and products like them that can be tailored and upgraded, never do customizations to the product to meet your needs. Adapt your needs to meet the standard. And remember you are buying a relationship as well as a product.
Now you are in a position to buy. I’ll leave the commercial aspects to someone else, or maybe a later blog. What do you think/ Do you instinctively do this? Or something else? Have you used this successfully? Let us know – comment below!

Get better at buying stuff – why keep doing it the wrong way?

So you might say “I’m great at buying stuff, I don’t need any help”. You might be more likely to say “my spouse / significant other / child is great at buying stuff and I need them to do it less!” Either way, with a little learning effort you can improve the way you decide what to buy. Read on to find out how.
But it’s all a question of scale. The bigger the purchase or its impact, the more this applies. For smaller, low impact purchases, this is usually not appropriate (but some of the underlying principles may fleetingly apply).
Getting it right goes like this: What do I need? What are the options? Which is best? Decision. Sounds simple. It is.
So how do I get to what I need? First let’s understand the difference between “want” and “need”. The best way to describe the difference goes something like this. I want a Ferrari. My wife says I don’t need one.
But seriously, a want is an idea, possibly an impulsive idea, which is often an emotional reaction to a perceived need. Maybe advertising generated your want. Maybe a perception that things are stagnating and you need to keep up. Maybe excitement about a possibility or idea you have had. Maybe even envy. Maybe even genuine consideration that something new must be acquired for real benefit.
The key at this stage is “why”. Why do I want this? What benefit am I really seeking to achieve with this anticipated acquisition? And this requires honesty and self-awareness. Not just domestically, but at work too. In large, global enterprises. Really.
A great way to do this is to list the consequences of not buying what you want. And all of the negative consequences of buying it. For example, if I don’t buy that new car I will have more money for my vacation. And if I do buy the new car, rather than keeping the old one, I will have to take greater care about where I drive; no more charging around muddy country lanes!
So now you’ve decided that you really do want this new thing. So we can now say that you need it. I wanted my Ferrari, but it couldn’t take all of the clothes my wife likes to buy on shopping trips, so I know I need a new car, and I know I need a capacious trunk.
It’s time for more detail. What are the features you need from this new acquisition? Start by writing down as many features as you possibly can. The more the better. Ask others to help. We are looking for quantity of features here! Don’t worry if you think the features are not relevant or may not be needed.
Then, for each feature in the list we come up with a rating. The ratings go like this. Essential. Important. Desirable.
  • Essential means “I will not acquire the item unless it has this feature”.
  • Important means “I am prepared to acquire the item without this feature, but it will be inconvenient”.
  • Everything else is Desirable, which basically means “don’t care if it has this or not”.
If what you need to acquire affects more than one person do this activity together (even consider doing it independently first, and then having a debate). Do you think this could help with planning your next family vacation?
And now you have an objective assessment of what you need. So the next step is what is available to meet your needs. We’ll talk about this in part two of this blog (coming soon!).
REMEMBER: when you want something, try to focus with objectivity on why you think you want it. If it passes your objectivity test, the chances are you need it. And to get better really quickly, consider signing up for our Software Acquisition Service.

What skills do you need as a Business Analyst?

You are just starting to embark upon a career in business analysis. Where do you start? What do you need to learn?
Let’s uncover some of that information for you, and point you to some resources that will help with your research. First off, let’s look at a definition of what a business analyst is. This comes from the IIBA:
“Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”
One of the first questions I often hear is something like “do I need domain knowledge (that is, knowledge of the business area in which I will be a BA) to be a business analyst?” The answer is no. I suppose a little knowledge may help, but your job as a BA is to elicit the domain knowledge from subject matter experts (those who know the domain because they work in it, and are experts). Almost by definition, you cannot be a subject matter expert and should not be a subject matter expert in anything other than business analysis. For some reason this is a controversial statement; reasoned arguments welcome in the comments for this blog!

So what qualities do you need demonstrate to be a successful business analysts?

At the most important level it all comes down that which it is difficult to quantify:
  1. Excellent interpersonal skills.
  2. Clear thinking.
  3. Confidence.
  4. Determination.
  5. Critical thinking.
  6. Objectivity.
  7. The power to inspire and win confidence.
  8. The resolve to see the big picture and deal with ambiguity.
  9. A love of simplicity.
Getting more specific; an ability to know how to:
  1. Facilitate change
  2. Interview
  3. Lead
  4. Communicate verbally, in writing, and in pictures, with clarity and authority
  5. Organize
  6. Plan
  7. Measure
  8. Present
I am sure this sounds like a lot! And it probably sounds intimidating. But don’t be put off. Because business analysis can be a lifetime career in to which you gradually grow from beginner to expert, from dealing with well defined, simple issues to the most complex business problems imaginable. A continual challenge, gradually building on past experience, the experience of others, and always learning.

 So where to start?

A course in Business Analysis is a great place, especially those offered with an IIBA endorsement. I know this is a good one (disclosure: I am one of the three lecturers!) Take a look at Purchasing Therapy for advice on the right way to go about finding what you really need before acquiring any of the materials recommended here.

What else can you do? And what if the expense of a course is beyond your financial budget right now?

Read. Look at these great resources, both books and web sites, free and paid
Join a local BA User Group. Seek out a mentor if you are currently employed, who can help you learn and apply analysis skills.
Carefully consider the qualities of a BA listed above, and if you feel you are a good fit for the role, persevere!
Also, look at finding training courses based on the “abilities” listed above. Classes are easy to find in any of these categories, and are generic, and easier to justify with your current employer.
And by the way, we also so have some information on starting your BA job hunt.