Tag: Requirements

Best of BATimes: 99 Tips To Be A Fantastic Business Analyst

Written by Bronia Anderson-Kelly on November 10, 2022. Posted in Articles.

Published on August 29, 2019

1. BA yourself

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 analyze 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 organization.

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. Maximize 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 organized 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 instill 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 organized 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.

19. Model

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. Categorize 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 vocalized. 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. Recognize 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 recognized 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 prioritizations 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-prioritizations 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 maximize the product and minimize 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.

(See www.batimes.com/articles/personal-growth-through-discomfort.html)

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 plagiarize

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 organization start to build a repository as you work. Have one eye on how a future project may use the template. If your organization 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 flavor

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-energize you ready for the next task.

71. Speak up

If you see a possible method of improvement have the courage to vocalize 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 pressurized 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. Organize 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 mind map 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 = 1^st 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.

To BA or Not To BA: Why Every Team Needs Business Analysts

Written by Katie Cubitt on October 13, 2022. Posted in Articles.

The importance of having a business analyst (BA) on your team can’t be overstated. Acting as the bridge between stakeholders and technical teams, the BA wears many different hats. On any given day, a BA can be expected to work on a number of different tasks, whether that’s defining business cases, validating solutions, or even working with data (See this article on the role of BAs in an increasingly data-driven landscape). Able to straddle both worlds and speak the language of businesspeople and techies alike, BAs really are one of the most versatile members of the team.

The Story of an Ask

Many businesses are concerned with their ideal state, while the nitty gritties of how to actually get there are very much back of mind. “Often, the client is not able to fully explain what business problem they wish to solve and how to translate their business requirement into language the technical teams can understand,” explains Lizande Botha, a BBD project manager for a major financial services client in Africa “which is why BAs are a vital part of the process”. Put simply, BAs are responsible for translating a business ask into detailed requirements that can be understood and actioned by technical teams.

But how do we get to this point, when the ask itself is unclear? “The first question I tell the BA to ask the client is: What is the problem we’re trying to solve?” explains Botha, adding that the cardinal role of the BA is to ensure that the client ask is clearly defined. “For clients who really are unsure of what it is they want, the BA needs to keep digging and asking questions to truly get to the core of the problem” she adds.

Once this key piece of information has been gathered, the BA can start drilling down into the different possible solutions, what the budget is for the project, and other confines or expectations the client might have. Understanding the requirements and clearly defining the scope of any given project from the get-go can be make or break – so much so that CIO magazine reports that up to 71% of failed software projects can be attributed to poor requirements. Thus, consulting with a BA at the start of a project can avoid potential stumbling blocks.

While this early engagement is vital, the job of the BA doesn’t start and end there. Leveraging rapport built with business stakeholders, they must check in regularly to provide progress updates, while ensuring that on the engineering side things are running on course and to the requirements of the client’s business. They’re even able to partake in platform or application testing. Truly, the BA’s impact is felt throughout the project lifecycle!

BBD’s Drive to Help and Resolve

BBD’s teams are all complemented with BAs who are well equipped with experience and a thorough understanding of the industry they’re operating in. As each industry offers complexities unique to its environment, BBD strives to best match their analysts to sectors where they can bring their experience and real-life learnings to the table, explains Botha. This is a high priority for BBD, a software solutions company which delivers software solutions for clients across the industry spectrum, from financial, education, public sector, gaming, and beyond. Assigning BA’s that already understand the nuances, jargon and processes of a particular industry enable us to expedite the solution process” says Botha

But beyond managing teams to ensure the best hands are on board, BBD is ready to tackle any problems their clients have. And when it comes to understanding what those problems are, BBD has BAs on call to bridge the client-engineer gap and ensure the success of all of their solutions.

Looking for a software partner to help you on your next ask? Get in touch with BBD.

Best of BATimes: Business Analyst Jobseeking tips – Acing The Interview

Written by Adrian Reed on October 6, 2022. Posted in Articles.

Published on: January 7, 2021

The business and economic environment is incredibly tough right now, and I know from conversations with some of my connections that it’s a tricky time to be a BA jobseeker.

Competition is rife and it can be a challenge to know how to really shine in a job interview.

I recently facilitated a webinar panel session with Michelle Shakesheff and Saffron House (two senior BA managers) on this very topic. This article summarizes some key takeaways from that session, with a few of my own thoughts added in for good measure. It’s important to keep in mind that I’m based in the UK, so I’ll be reflecting on the expectations for job interviews here—I am sure expectations differ across the world so be sure to check out other articles and resources too.

Preparation Is Everything

When it comes to a job interview, preparation is everything. There are many aspects that need to be considered, including the three ‘Rs’: Research, Role & Rehearsal.

Firstly, if you’re serious about working for a particular organization, then it’s crucial to research it. This doesn’t have to be time-consuming, can be entirely ‘desk-based’ and is an opportunity to use a range of strategic business analysis tools. You’ll want to check out the organization’s website, if it’s a large organization it’ll probably have an annual report. What is its stated mission and strategic objectives? What are its stated values? Techniques such as VMOST can be useful for helping us to understand where a company is heading. Approaches such as STEEPLE are excellent for brainstorming external factors that might affect the organization. You might want to assess what you consider to be the biggest external opportunities and threats to the organization. Utilizing these (and other) techniques alongside general research will provide a picture of the types of project that a company is likely to be undertaking. You’ll pick up the language of the industry and organization, you’ll be well-placed to give specific answers to any strategic questions that the interviewer asks even if these don’t crop up, you’ll be well-placed to ask a relevant question about the organization’s strategy. You’ll also get a sense of whether this is a company that you’d fit into and actually want to work for!

Secondly, there’s the role. Read every detail of the job description, person specification and whatever artefacts you can get your hands on. Think back to your experience and be prepared to give an example for every skill or competency that is listed. One senior manager I used to work with always advocated creating a table to systematically work through a job description, breaking it down into its component parts and adding an example against each. If you do this, you’ll have the right example on the tip-of-your-tongue and won’t hesitate if a question crops up. Here’s an example:

Requirement on job spec	My example	My contribution	The outcome
*Process modeling & analysis*	XYZ Project: analyzed 25 processes, proposed improvements. Used BPMN.	Led process discovery, as-is and to-be modeling. Resolved conflict through workshopping.	All processes were implemented. Stakeholders loved the new processes as they’d been involved throughout.
*Resolving conflict*	ABC Project: Removal of permanent desks.	Ran a prototyping session so ‘hot desking’ workers could see the benefits.	Stakeholders who were reluctant became advocates.
*Analyzing business rules*	Etc.	Etc.	Etc…

Finally, there’s the rehearsal. I remember hearing polar explorer Allan Chambers speak over a decade ago. He gave the sage advice ‘never take your body somewhere your mind hasn’t been’. This applies for interviews too: take your mind to the interview room (or virtual interview room). Imagine the types of questions you might encounter, formulate your response, and say them out loud. What is the first thing you’ll say to the interviewer? You’ll get different questions on the day, of course, but you’ll feel more confident and prepared and your answers will likely be slicker and well-informed. This brings us neatly to our next topic, questions.

There Are No “Top Ten” Interview Question Lists

Although this might sound disappointing, there really aren’t any “standard” BA interview questions. There might be patterns that crop up, but the questions are going to vary depending on the specific requirements for the role. It’s also highly likely that there won’t be a “right answer” to any particular question—put yourself in the shoes of the interviewer and think what are they trying to understand from this question? And don’t be afraid to ask for clarification. It is genuinely hard to create unambiguous interview questions, and speaking personally, whenever I’ve been involved with interviewing candidates I take requests for clarification as an extremely positive thing. After all, BAs ought to be clarity-seekers!

It’s also important to answer the question that’s asked, not the one that you might have hoped the interviewer has asked. I’ve fallen into this trap myself in the past, and I can tell you it doesn’t end well… However, if you’ve considered the different areas of the job specification and have examples for each area you’ll be well prepared to pivot and adapt on-the-fly.

A word of warning here. One trait that seems to be common amongst most BAs I’ve ever met (myself included) is the tendency to say “we”. As BAs we work with others, and a success is a team success. This is fine in most circumstances, but job interviews are a place to say I as well as we. By all means discuss what the team achieved, but remember the job interviewer is going to want to know what you contributing. Hearing “We created and prioritized a backlog” is interesting. Hearing “I worked with the PO and coached them on the user story format. We experimented with different formats, but settled on user stories with some attached scenarios and acceptance criteria, which I wrote on behalf of the PO…” is more useful. Precision is great.

Talking of precision, frameworks can act as a common language. Being familiar with industry frameworks such as IIBA’s Business Analysis Body of Knowledge guide (or whichever is relevant for your context) can help. Using industry standard terminology such as requirements elicitation, strategy analysis, requirements lifecycle management and many, many more besides will help ensure that you and the interviewer are on the same page. Of course, it’s likely that the organization will have its own internal framework. If you’ve been able to learn about that in advance through your research, then use those terms too.

Remember: An Interview Is Two-Way

It might seem like an interview is purely for the employer, but this is far from the truth. It’s also you’re opportunity to assess whether the organization is a good fit for you. Do the interviewers treat you respectfully? Do they keep failing to turn up for the interview at the last minute without explaining why and then re-arranging? Keep in mind that an employer that treats candidates without due respect may well treat employees similarly.

On the flip side, you may well find you get on fantastically with the interviewers, and all of your instincts are that this is the job for you. Be sure to take the opportunity to ask the interviewer questions too. You might ask them about the size of the team, the challenges they are facing—this might be a chance to showcase the research that you’ve done and ask them a specific question about the strategic direction of the organization and how it impacts the BA team. Choose the right questions for the context, and use it to learn about the organization and the role.

Conclusion

Job interviews are nerve-wracking, but those nerves push us to prepare and perform well. Remembering the three Rs: Research, Role & Rehearsal, thinking about the questions that might be asked and remembering an interview is a two-way process can help.

Best of BATimes: A Checklist For Business Analysis Planning

Written by Edmund Metera on September 8, 2022. Posted in Articles.

Use the Universal Business Analysis Planning Checklist as You Plan Your Business Analysis Approach.

Every project is a unique, temporary endeavor.

The business process management, regulatory compliance and digital transformation projects that business analysts may play a role in all come with different goals, scopes, teams, timelines, budgets dependencies and risks. Though many projects follow similar methodologies they are all tailored for project scope constraints and to take advantage of available resources, opportunities and lessons learned from prior work.

Each business analyst also comes with a unique set of skills and experiences. Almost all business analysts have great communications skills and at least some experience-based business domain knowledge. That’s why they became business analysts in the first place. Every business analyst has uniquely acquired knowledge of business analysis techniques and business domains through personal study, practice and experience. Many have also been trained in elicitation, requirements management, modeling, measurement, analysis and documentation techniques. An ever-growing number have received professional certifications, such as the IIBA Certified Business Analysis Professional (CBAP) or the PMI Professional in Business Analysis (PMI-PBA).

What is Business Analysis Planning?

The most skilled business analysts are not only competent in many business analysis techniques but also consciously tailor their business analysis approach for each project that they engage in. They have learned to consider key project dynamics along with their own competencies and to tailor their planned business activities and deliverables to suit each project’s unique dynamics. Regardless of your own level of business analysis experience, maturity, and whether you are formally trained, certified or not, you can still consciously assess each project’s dynamics and tailor your forthcoming business analysis work to get the most productivity and value out of your business analysis efforts in each project.

The most significant project dynamics include:

The methodology, or sequence of stages or major milestones, and the business analysis products or outcomes that are expected by the end of each stage/milestone (and before starting the next).
The budget and schedule, not only to meet them, but to take advantage of contingency or schedule slack opportunities, to increase the value, quality or to learn.
The key project stakeholders and relationships that are new and changed and forming, to take a proactive role in fostering and building relationships with and among that team.
The types and combinations of elicitation techniques that will be best suited for producing or validating business analysis deliverables.
The business domain knowledge and experiences of the diverse key project stakeholders, including your own unique set of business analysis competencies.

The Universal Business Analysis Planning Checklist

You can be more effective in planning your business analysis approach if you follow a consistent, clear agenda that considers the common project dynamics.

The Universal Business Analysis Approach Planning Checklist covers the most common project dynamics. You can use this as an agenda to elicit and discover a comprehensive view of a project’s key dynamics, its opportunities and use what you discover to adapt/tailor your business analysis approach.

As an exercise, think of a project that you have recently worked on, you are currently working on, or will soon be working on. Answer questions in the following checklist for yourself.

Project Life Cycle

What are the planned stages of this project?
What stage are we currently in?
What is the business analysis deliverable (or set of deliverables) that I am responsible for producing in this stage?
What is the intended use of my business analysis deliverable(s) and who will use it?

Schedule And Effort Budget

How much effort can I spend and by what target date am I expected to produce my business analysis deliverable(s)?
Is that about what I also estimate it will take?
Is either my effort or date estimate higher than the effort budget or target date? If so, how might I adapt my effort, scope, activities or configuration of my deliverable(s)?

Project Stakeholders And Relationships

- What are the key roles is on the project team and who is in them?
  - Does this project have an executive sponsor, project owner or product owner, project manager, specialists and business subject matter experts?
  - What are the names and titles the persons in these project roles?
- Are significantly new relationships being are created in this project?
  - Who’s new to each other on this team?
  - Are there local and who’s remote team members?
- What are peoples’ responsibilities?
  - Who is responsible for producing, accepting or needs to be consulted or informed of each of the project’s key deliverables, particularly the business analysis deliverable(s)?

Elicitation Techniques

Which elicitation techniques are available to me use?
- Documentation Reviews – What documentation or prior work products are available to review?
- Interviews and Workshops – Who can I interview or include in a workshop, and what questions would I need to ask?
- Observations – Where and what kinds of observations may be needed and how could I arrange for them?
- System reviews – What system(s) are available to review and for what information?
- Surveys – Who could I engage in a survey and using what types of questions?
What are my own business analysis competencies?
- Considering this project’s stakeholders and relationships, the elicitation techniques available to me, and my own core competencies, which elicitation techniques are best suited gather and validate my business analysis information?

Organizational Assets

What specialized tools for elicitation, documentation and modeling are available to me?
- Collaboration tools, facilities, survey tools?
- Diagramming or modeling software?
What prior business analysis work (e.g., documents, models) that I can draw from?
Does my organization offer training in the subject business domain?

Competencies And Knowledge

Who on the project team has what expert business domain knowledge?
What is my own business domain knowledge?
What are my strongest core business analysis competencies?
Where can you take advantage the team’s diversity of knowledge and competencies?
Who are the best stakeholders in this project to engage in elicitation of content or validation of business analysis deliverables and what is or are the best elicitation techniques to use?

On reflection, are you able to answer these questions for yourself? When you go into your project workplace, who will you include in this conversation?

Conclusion:

Business analysis planning is a recognized business analysis activity. The IIBA Body of Knowledge (BoK) includes the Plan Business Analysis Approach activity within its Business Analysis Planning and Management process. The BoK also lays out the scope of what should be covered by a Business Analysis Approach as “The set of processes, templates, and activities that will be used to perform business analysis in a specific context.”

The time and formality that you apply to business analysis planning is up to you. At the financial institution where I work as a project and program manager, our business analysts typically tailor and document a business analysis plan for each new project to which they are assigned.

I think of business analysis planning as a form of insurance. Spend a little time upfront to assure that the bulk of the rest of your business analysis efforts will be as well spent and effective as possible. Expect the benefits of tailoring a business analysis plan for every project to be that:

It will help you to align your own core business analysis competencies to each project, and
You and the project will gain the most value from your business analysis efforts.

That’s a value-adding proposition.

You are welcome to contribute comments about project dynamics that impact business analysis plans or about the checklist presented through the Contact Us page at www.ProcessModelingAdvisor.com.

Did You Know That a Business Analyst Is as Important in Software Testing as a QA Specialist?

Written by Alex Khomic on August 18, 2022. Posted in Articles.

An IT Business Analyst is a member of a product development team. Such specialists are involved in all stages of the SDLC, from requirements gathering to software launch. They not only connect project teams with customers but also know the peculiarities of products in detail, resolve disputes and advise how this or that software solution should work according to the requirements. They are also an authoritative source of information for QA professionals. Let’s take a closer look at the role of a Business Analyst in software testing.

Primary responsibilities of a Business Analyst on a project

A Business Analyst represents an IT outsourcing company team at the first meeting with a customer and remains the main contact person for product development until the end of a project. This specialist informs developers about the client’s interests and makes it possible for the product owner to give feedback on the software. Business Analysts help to carry out business communication, and any project starts from their work. The main responsibilities of these experts can be briefly described in four theses. A Business Analyst:

Helps businesses to study the market and current offers to learn about competitors’ strengths and weaknesses and thus build the best application. Analyzing market trends, a Business Analyst foresees what will be relevant for users at the time of product release. As a result, the platform will be interesting for the target audience and function properly from the first day of launch.
Advises the client on how to develop a product with minimal investment and maximum ROI in the future. Using the results of market research and relying on the capabilities of the client, they offer a “silver bullet” to solve business problems so that the customer achieves the desired goals at a lower cost.
Prepares documentation for the project which is a kind of “bible” for the development team. Based on it, programmers write code, designers prepare layouts, and testers create test cases. Thanks to the specification, customers track the progress and make sure that the software meets their vision and the project goes according to plan.
Advises the development team on relevant issues. Such an expert knows more about the product being developed than other team members. This fact makes them the main product consultant who will clarify any requirements.

“But what about testing?” you may ask. Let’s figure it out.

What does a Business Analyst have to do with software testing?

As we have mentioned above, an IT Business Analyst prepares the basis for a project and launches the work of all team members. Requirements prepared by this specialist become a guideline for developers, testers, and designers. Business Analysts do not directly test the product, but participate in the following procedures:

Preparation of test documentation. A Business Analyst checks the correctness of test cases, helps to generate test data and suggests an improvement plan.

This specialist signs a test plan if authorized to do so and checks if existing scenarios match user stories.

A Business Analyst prioritizes requirements and features and changes the priority if the conditions on the project change.

Such an expert helps to make sure that the detected incorrect behavior of a system is a defect. QA specialists focus on requirements in their work, but if they do not understand certain points, they turn to Business Analysts to clarify the details, examine bugs, and tell if these are bugs indeed or the intended behavior of the program.

This IT professional resolves disputes between developers and testers. Even if the requirements are written and collected, this does not mean that everyone understands them in the same way. A developer and a tester may see the functionality of a feature in different ways, which can lead to arguments about whether this is a defect or a FAD (feature as design). To resolve the situation, a tester also turns to a Business Analyst. Their resolution is considered decisive.

The more accurate and understandable a Business Analyst describes the requirements for a product, the fewer mistakes developers and testers will make. This means that they will complete the work faster, the functionality will not have to be redone, and the project budget won’t be wasted.

The role of a Business Analyst in testing

An IT Business Analyst is an authoritative member of a development team, whom QA specialists turn to for advice at any stage of testing. This expert knows the functional and non-functional features of the application being created, so their word on the project is the law. A QA specialist seeks advice from a Business Analyst when conducting:

Functional testing. A Business Analyst explains the business logic of the project and points that are incomprehensible to a tester.
Regression testing. Based on critical business functions, a Business Analyst advises which test cases to include in this testing phase.
Usability testing. For a Business Analyst, it is important that the application is as convenient as possible and has demand in the market. This will allow the customer to evaluate the performance of this expert and their foresight. They also recommend to testers how to improve a particular functionality to increase the quality and value of software solutions.
End-to-end testing. To create end-to-end tests, a QA specialist needs to understand an application, its business logic, and user scenarios. In this case, the tester will be able to use the important details for each function: the correct input data, the exact restrictions, the correct sequence of steps, and different ways to call a function.
Acceptance testing. A Business Analyst confirms that the product meets the business requirements.
Beta testing. IT outsourcing company testers are not involved in this type of testing. In this case, real users work with the application. A Business Analyst observes this process, notes what needs to be improved in the product before its release, and makes sure that the application is really valuable.

Conclusion

Thus, a Business Analyst is not just the owner of the requirements on a project or a translator of a customer’s ideas. Any development team needs this expert at every stage of the SDLC, in particular during software testing. Business Analysts are responsible for quality and compliance with requirements, that’s why they participate in many project activities: from the specification of requirements, and approval of test cases to UAT testing control. Only in this case, the planned functions will be correctly implemented, end-users will be satisfied, and the client will receive the desired profit.