This is one thing that only some professions can do. An Actuary can’t actuary himself, a developer can’t code herself, a mechanic can’t mechanic himself. We can analyse ourselves. Use your skills. Decide what a fantastic BA is; research, interview, question and then review yourself. Do some gap analysis and then formulate an action plan.
2. Be nice
No one wants to work with a jerk. No one wants to help and supply information to a jerk so engender support. Thank people, go out of your way to be personable, establish friendships and mutually positive working relationships.
3. Understand project lifecycles
Get to know all the steps in project lifecycles, not just your own and especially the intricacies and peculiarities of the adaptation used by your organisation.
4. Be a mentee
There is much to be learned from Analysts further along the road than you.
5. Present well
Don’t dress like a scruff, smell nice, clean your teeth. These are surely basics but I have met people in business who have overlooked these things and they are avoided. You can’t be avoided and be successful.
6. Prep prep prep
When you go to meet a stakeholder, especially for the first time, prepare. Understand who they are in the business and project context. Ask them for any pertinent information to be sent for your review in advance. Maximise the time with them to appear (or be) effective and efficient and they will happily give you more.
7. Be on time
Your prompt arrival in the office and at meetings will give you more poise than if you rush in late. It is the fruitage of an organised and self-correcting individual.
8. Work on your confidence
We’re not all naturally confident but by reassuring ourselves of our abilities in our BA skills or in our industry knowledge we can instil the needed confidence and trust from our business stakeholders that we can understand their world view and needs.
9. Don’t reject difficult things
They help you grow. Be the BA that accepts unusual assignments and see your career enriched and flourishing.
10. Get good at cost benefit analysis
Don’t leave this to the PM. At project inception, or for minor changes, be able to determine with appropriate certainty whether to accept or reject activity. Maintain a project which can stand-up on its own merits.
11. Be optimistic
Pointing out the bad may be necessary but if you find yourself always the nay-sayer then fix it. Problems are our business. Our optimism can make for a gentler change process.
12. Get your desk in order
Give your workspace a make-over. Keeping it clean and orderly can help you be organised and looks a lot more respectful.
13. Go to a conference or two
Hear some new stuff. Mingle with your peers. Feel proud to be part of a greater something.
14. Help others
You have a project deadline, sure, there’s always one looming but give your fellow BAs your assistance. It will broaden your knowledge and strengthen your team.
15. Be strict about your change management
Keep a record of changing requirements and details about them. It will save you the red face when, inevitably, someone will ask you later for paperwork.
16. Do your actions
If the PM has to continually chase you for your actions they will resent it.
17. Don’t be offended by the red pen
Your work will be reviewed, heavily. Welcome critique and correction. Never be upset about any proposed edits. The individual has spent time immersing themselves in your work and for that you can be grateful. It will make your work better, or at least more acceptable to your audience.
18. Volunteer to share your knowledge
Blog, post, present at lunch-and-learns, write-up how-to guides. There are always people who don’t know what you know so share.
Use models a lot. Business people invariably find models easier to verify than paragraphs of information and it brings the potential delivery to life. Architects, Developers and Data Analysts thrive on a well-produced model.
20. Learn, learn and learn some more
If you have the means then don’t stop learning. There is so much training available in BA skills, industry knowledge, peripheral project skills, business knowledge, techniques and soft skills.
21. Offer plentiful walk-throughs
By walking-through your outputs with developers, testers and business representatives you reduce the risk of misinterpretations.
22. Finish your projects
This is especially true if you are a contractor. It’s not good practice to leave a project part-way through if you can help it.
23. Develop strategies for juggling
You will have to work on many things at once. Find what works for you to avoid loss of productivity. If you have yet to nail this there are plenty of productivity tips and hacks on the internet.
24. Clear paths for people
Be someone who anticipates down-stream problems and blockers for yourself and others and intervene.
25. Categorise people but know your exceptions
Use personality and character traits to help you understand the motivations and reactions of your team but note that exceptions exist. Tailor your interactions to fit.
26. Don’t jump to solutions
Have problem-formulating conversations to focus your mind away from solution-mode.
27. Form collaborative relationships
When you collaborate you are more likely to get early and continuous buy-in, nothing will come as a surprise to your end client and you get immediate feedback on your work. It’s worth the extra effort.
28. Find your key SME voices
The quality of Subject Matter Experts is not equal. I have seen business users hide information for a variety of reasons (most understandably) making elicitation more than the usual effort and I have had System Testers guess answers and present information as fact. Hunt for good sources of information and verify what is said.
29. Play requirements back
Saying things like: “So if I understand this right, what you needs is…” saves misunderstanding.
30. Work to uncover implicit requirements
What assumptions have you or your customers made that they haven’t vocalised. Set aside some time and thought to uncovering these.
31. Know your audience
The level of detail that you go to should reflect your audience, know this before you start your elicitation. Get it wrong and you either waste time or have to re-work.
32. Recognise that accuracy is important
Particularly in your written English. If you can’t get that right, what else might get called into question.
33. Start with context
Ask: “Why the project exists?”, “What will be the end results?”, “What benefits are sought?” Then work from there.
34. Document what you won’t build..
..and get it agreed. It doesn’t mean it can’t be changed but it will at least be recognised as a change rather than something that you missed.
35. Get creative
With care not to promise an outcome, suggest ideas and alternatives to users during elicitation. Possible options can be used as a sort of model to tease out other requirements.
36. Read widely
The IT industry is constantly changing and working practices follow hot on the heels. Our understanding of business practice, psychology, methods for collaboration and effecting change progresses. Manuals, how-to guides and handbooks to support our work are plentiful.
37. Don’t forget your non-functionals
If you don’t include these in your document template as standard, add a section for each non-functional as a reminder to consider it.
38. Don’t gild the lily
It may not be scope creep as such but it’s easy to gold-plate our requirements with unnecessary items. Admirably this is usually in response to wanting to deliver the best but these types of extras add up. Work out what your Minimum Viable Product is and then be sure to note any additions as just that.
39. Revisit your prioritisations often
Work with your group of SMEs to get your product features delivered in the right order but remember that things change so schedule re-prioritisations throughout delivery.
40. Evaluate your own skills
Choose a couple of areas for improvement, write them down and formulate some actions that will help you improve them.
41. Look for “free”/cheap benefits
By knowing what’s off-the-shelf or can be achieved with relative ease you can maximise the product and minimise the cost.
42. Ask for feedback
At suitable points during and at the end of projects get personal feedback. Asking people who will give you constructive critique is valuable. Keep it. In years to come you can see how this helped you to change and grow.
43. Find balance
Don’t neglect your personal life. Finding a good work-life balance helps you cope with the ups and downs of projects.
44. Connect with others
Associate with other Business Analysts. Everyone knows different things and that diversity is valuable. Learn, share, help and be helped.
45. Know when to shut up
You’ve raised a risk or an issue but no action has been taken, so you raise it again or differently. It’s good practice to be assertive but there comes a point when you have sufficiently noted it and taking it further causes consternation. Learn where that point is and stop before you reach it.
46. Be a mentor
You know more than you think you know. Give back to the profession by sharing that with someone following in your footsteps.
47. Work as a team
When you work with other BAs, even if you’re tasked on different items, work together. Peer review, support, offer and ask for opinion and share experience.
48. Make your research visible
If you do background reading, conduct surveys, read manuals, hold workshops then put your findings as links or appendices to your documents. Don’t make someone who may need to pick up your work at some later point have to start from scratch.
49. Expand your comfort zone
Do something a little bit uncomfortable, just a little. It will make you capable of more in the future.
50. Be agnostic to the solution
If you begin with a pre-determined solution or have a particular software package in mind you won’t be working on behalf of your client.
51. Be flexible to software development lifecycles
Learn to work waterfall, agile, fragile, whatever your client wants. Help them build on what they have.
52. Work with positive people
When you get a choice, pick to spend your work hours with optimists. Lift your chin up and thrive with them.
53. Don’t plagiarise
It’s fine to get inspiration from other text but word them in your own way. The process of breaking something and re-working it allows you to assimilate it properly.
54. Create your own templates, improve others
If templates don’t exist within your organisation start to build a repository as you work. Have one eye on how a future project may use the template. If your organisation does have templates, seek ways to improve them.
55. Hone your toolkit
Rich pictures, sequence diagrams, business model canvas, running workshops.. and the other scores of tools and techniques in the BA toolkit. Practice them and then get them into your workplace. The more the merrier.
56. Encourage newbies
We were all new once. The profession is constantly refreshed with new and trainee BAs. Welcome people. Help them.
57. Don’t get stereotyped
Take on projects in areas that you haven’t done before so that you have experience and confidence in delivery in as wide a range of topics and disciplines as possible.
58. Avoid too much future-proofing
While it’s a very useful consideration some attempts at future proofing just don’t fit with the future when you get there. Unless it has wide application and has relatively no cost or impact to the project don’t overengineer it.
59. The devil is in the detail
Ask for detail and then spend time understanding complexities. If you don’t, annoying requirements will rear their ugly heads later, when you’re further down the road than is desirable.
60. Order your own tasks
It’s in our nature to do enjoyable things or things which are easy or small first and then rush others. Avoid this by monitoring deadlines and dependencies taking into account impacts from other people and their availability.
61. Decide what your goals are
Ask yourself where you want to be in 5 years and put a plan into place. It may be various certifications, it may be working on certain types of projects, with technologies or in specific locations. Work out the steps you need to get there.
62. Ask for help
No man is an island. There is no shame in asking for help whether about your career, with techniques or technical aspects.
63. Archive and catalogue
Don’t leave files, part finished documents, reference material and other artefacts as collateral damage of your work. Archive your documents, catalogue your information and generally make it easy for people to work out what are the most recent versions and what supports them.
64. Have a to-do list
Don’t risk forgetting important tasks for something as simple as keeping a list. Be organised.
65. Its ok to make mistakes
We are human and mistakes are inevitable. Know that you will make them and decide that dealing with them diligently and humbly will be appreciated and respected.
66. Estimate using metrics
If you’re asked to estimate for a piece of work, use quantitative methods as much as possible and share the information on which it is based.
67. Add a glossary
I have not seen a BA deliverable yet that hasn’t benefitted or would benefit from a glossary (either within the document or at project level). To determine what goes into it, consider your audience. You may need to add business terminology to give framework from IT readers and IT and project terminology for the business.
68. Vanilla is not the only flavour
Don’t forget about alternative flows. The abnormal activities are generally the pain points for most businesses. Overlook them at your peril.
69. Get your must-haves right
The MoSCoW rating is incredibly useful and the priority of requirements must be stated explicitly but it is only useful if you have ratified that a must-have requirement is absolutely necessary. Double check.
70. Chunk up your work and take breaks
By creating a series of much smaller tasks you maintain motivation as you complete activities and as a result have natural break points to re-energise you ready for the next task.
71. Speak up
If you see a possible method of improvement have the courage to vocalise it, respectfully and professionally.
72. Flesh out a plan but be flexible
Plan your assignments in a work-breakdown structure, so you can keep an eye on your own progress but don’t be too rigidly stuck to it that you can’t make the most of stakeholder time when they are available.
73. Do it now
If you get the choice between doing it now and doing it tomorrow; do it now. Procrastinating individual items adds up to lost time and missed deadlines.
74. Be motivated and committed
Volunteer enthusiastically, actively pursue end goals, deliver on your deadlines.
75. Find your USP
Maybe you’re a people person, good with data, can see the bigger picture, are an influencer, have specific technical expertise or domain knowledge, run killer workshops, are highly accurate….everyone has a unique selling point. Whatever it is, find it and use it.
76. Be an observer
Keep an eye on what your peers are doing. Look for cross-over and gaps between their work and yours.
77. Don’t cut corners
Guessing, not completing research fully, ignoring the quiet opposing viewpoint, not determining the full stakeholder group, failing to verify background information, removing valid approval stages are all ways to store up later problems. Don’t cut corners.
78. Run your own project
Is it possible to start a little business of your own? Doing this lets you really test your BA skills.
79. Display kindness and patience
When projects get pressurised this will make you stand out and be someone others want to have around.
80. Understand your Subject Matter Experts
Put yourself in their shoes. You’ve invited them to sit in a long meeting? Make it interesting, schedule breaks and bring biscuits.
81. Get your unfinished specs reviewed
Reduce your own risk of large rework by shipping parts of your document early and get feedback.
82. Take the initiative
Make suggestions. Improve your own team’s processes. Create bodies of knowledge. Organise socials Involve yourself.
83. Keep your requirements updated to the end
A change has been made at the eleventh hour, everyone knows about it, is there any need to take time-out to correct the documentation, especially when the pressure is on?….Yes. If you don’t, no-one will be sure of any of it in the future.
84. Take a step back
During meetings and workshops, take time to observe; interactions between people, gauge motivations. There is a lot more to be learned than comes in through the ears.
85. Control/Challenge scope
Consider scope constantly. It is the bread and butter of getting the optimal solution for the composite group of stakeholders.
86. Mock stuff up
User interfaces, documents, reports. Let your end users see and play with the final product at the design stage.
87. Minute your meetings
It doesn’t have to be War and Peace but make notes. Dictate, doodle or mindmap if it’s a more effective or efficient method for you.
88. Give people a “starter for 10”
People provide what you want more quickly if they’re not starting from scratch. If you have a template, provide it. If you want data, provide the table to be populated. If you want a quote, propose a sentence.
89. Learn standards
If there is a UML or ISO way of doing something then try to use it. It’s less ambiguous.
90. Use data analysis tools
Many Business Analyst roles include research in data. You can be more self-reliant if you are capable at manipulating it.
91. Use requirement ‘numbering’ for more than a unique reference
Use prefix letter, suffix letters and sub-numbering to store information about the source (stakeholder or actor), expected delivery method (various IT systems, manual processes, teams, department or companies) and dependencies on other requirements.
Eg, CS75-S.1 (CS = Customer Services, S = SQL, .1 = 1st child requirement)
92. Don’t be vague
Make requirements specific. Eg the phrase “needs to be run regularly” should be “needs to be run twice a day, usually at 12pm and 5pm” and the phrase “other systems use it” should be “three Access databases, listed in Appendix C, link directly to the data”
93. Find your best packages
Find and get proficient with tools and application supporting BA work. Eg, for producing and tracking requirements, for producing diagrams, flows and other models, collaborating and conducting meetings, managing work, etc.
94. Change control your documents
Applying version control saves your readers’ time. Be specific about what’s changed in your version history and use function for highlighting changes.
95. Understand development basics
Gain some knowledge in the basics of development; processes, data and events, components and re-use, integration with other applications, design principles and constraints. Learning to write in a pseudo code style can help with that mentality.
96. Understand test basics
Gain some knowledge in the basics of testing; test condition design, what a tester needs from your documentation.
97. Conduct Stakeholder Analysis
Don’t leave this to your project manager, do your own. Know who your influencers are, your VIPs and any potential “troublemakers”.
98. Ask effective questions
Questions are the keys that unlock treasure troves of information. Closed questions are useful when you need to be specific and open questions are needed to allow free-flow of knowledge transfer. Learn how to make them effective and unbiased.
99. Get qualified
There are a number of qualifications tracks available in various jurisdictions. International Institute of Business Analysis, British Computer Society and International Requirements Engineering Board. For gaining knowledge in the fundamentals as well as sharpening practitioner skills it is invaluable and a résumé necessity.