BA Skillset

Here are some skillsets and basic tools that I feel a BA should have:

• MS Office Suite
• Word
• Powerpoint
• Excel
• Access

Word & Powerpoint are no-brainers. Excel also; but more than a passing familiarity with Excel is a good thing. Knowing how to chart, use pivot tables, sort, filter, and even do some VBA are all exceedingly good things to know.

Learning Access is one of those things that can put you over the top. You can quickly create solutions for small groups of people and do a bang-up job. There're lots of instances where a simple Access database can do the trick but many BAs don't have the skillset to address them. Instead the project become overblown and a 3 tier solution with an Oracle DB and a middle tier and a web front-end are devised. This takes too long, is too expensive and more likely than not, you'll have to wait for resources to be freed up.

Training your users to use an Access Database is also probably a good thing to do. Lots of spreadsheet users invariably complicate their spreadsheets with tons of tables and VLookups, whereas a simple join in Access would do the trick.

Another useful thing with Access is if you do lots of data analysis. Comparing reams of data and figures on multiple Excel spreadsheets can get quite laborious and tedious. If you dump each of the sheets into their own tables in Access and do joins you can quickly find which ones match and which ones don't for example. Access (or knowledge of some database) is a must for the serious BA.

Other skills:

• SQL
• Communication/Writing Skills
• A strong desire to play with & learn new software; being a software evangelist
• An ability to filter out extraneous information and to focus on the details that drive a project forward rather than getting bogged down with too much detail: There's a time & place for everything. Sometimes getting all the information up-front is not such a good thing (your head probably won't be able to process it :)
• An inquisitive nature to find out what people do & why they do it. As a BA, you need to help automate things for your customer so you need to drill into all the particular details of what they do, what actions to take when certain events occur, when they do it, how they do it, how they know when to do it, etc. Getting the whole picture will eventually reveal the grand scheme and then you will be able to propose a solution.

A balance b/w taking into account the customer's concerns vs. ability to drive a solution forward is quite key: Let's face it. If you were to build a solution that took into account EVERYTHING, you would be in a quagmire. Automating error handling for every instance of something going wrong can be fruitless. Some things should just be manually handled. A lot of people, both BAs and customers get caught up in thought exercises and intellectual games following all kinds of paths to come up with some grand solution. Implementing something like this and then debugging it can be a nightmare. Remember that you need to not just satisfy your clients but your dev & qa teams should be considered as well. If your solution solves 80% of the customer's problems, then you should strongly consider pushing that forward. The rest can be 'phase 2-ed'. When I use this phrase, it allows the customer to relax knowing we can deliver something quick in phase 1 that'll handle most cases and then we'll handle the rest later. But you know what? Many times Phase 2 never even happens because Phase 1 is completely adequate!