Tag: Requirements

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.

The Courage to Try Something Old – Part 2: Scribing

Written by Elizabeth Larson on August 10, 2022. Posted in Articles.

In the previous article I wrote about the importance of facilitating requirements meetings and why it can take courage to do so. In this article I’ll discuss another skill that has fallen in and out of favor over the years—scribing.

Many ancient societies valued scribes. Scribes typically were at the center of all activities and highly regarded in the areas of government, law, military, and religion. Today’s scribes are not so universally regarded, particularly in our world of PMs and BAs. Effective scribes should be at the center of requirements activities, but most often they are not. We’re often in the back of the room or off to the side. We’re not always introduced in virtual meetings. Many organizations view scribes simply as passive note-takers and unfortunately that’s how many scribes view themselves. But I have found that scribes are essential to the success of the project.

What is a scribe and what does a scribe do? A scribe is the role that provides documentation, either formal or informal, and anyone can play that role. PMs, BAs, facilitators, business owners, QA analysts, programmers—it doesn’t matter what the title is. Any time we’re documenting our PM or BA work we’re scribing. Our output can include recaps of sponsor and other stakeholder meetings, requirements (models, textual, etc.), assessments, gap analyses, and business cases to cite just a few.

What skills does a scribe need? Like every effective PM and BA, the scribe has to create structure from chaos. That’s not easy so scribes need a variety of skills, such as listening, absorbing, clarifying, and writing. But perhaps most important is critical thinking, which comprises many skills including:

Conceptualizing – grasping what’s being discussed because we have enough context[i]
Applying – taking what we know from our experience and using it in new situations.
Synthesizing – absorbing lots of information, processing it, and making sense of it immediately.[ii]
Evaluating – knowing what’s important and what’s not, what works and what doesn’t.[iii]

Why do we need scribes? Documentation is important if for no other reason than because it saves time. We cannot possibly remember all the salient topics of our project and requirements meetings. Documentation helps prevent revisiting and revisiting again all the important decisions already made and who should complete which action items and by when.

How much courage does it take to scribe? Why in the world would it take courage to scribe? Because the most common scribing pitfalls relate to courage. I am often asked questions such as these:

What if the PM and/or team thinks it’s a waste of time to have a scribe?
What should I do when the facilitator wants to “take notes,” but in the end, much of the meeting is lost because the notes are too sketchy?
What should I do when I’ve been told to sit in the back and be silent when I take notes? Most of the time I have questions or want to clarify what’s been decided, but I’m told that asking questions will take too much time.
What should I do when I’m asked to distribute the documentation in an unreasonable time frame?
I know it’s important to recap the highlights of my scribing output at the end of the meeting, but we never seem to have time. Our discussions always run over.

If we are too timid to address these issues, we will be less useful not only to our project team, but the entire organization. But it takes courage to tackle them. We need to be effective at influencing, and courage is a main component of influence. We need to ensure that everyone understands the importance of both scribing and the scribe role, and it takes courage to point these out. It takes courage to speak up about the risks of not having scribes in organizations that don’t value them. And to link an unsatisfactory product delivered to stakeholders to effective scribing. And because it takes time to be an effective scribe, we need to advise including scribing tasks in project planning.

Finally, as scribes we need to be neutral and not have a vested interest in the outcome of the meeting. As we know, the person with the pen has the power and can rewrite the project’s history. Let’s not sneak in a couple of our or our sponsor’s favorite requirements, or conveniently forget any because it’s easier than seeking a scope change. And there’s no need to document every conversation– the key items like decisions and action items will do. When done well, scribing is a thing of beauty. When not, it might well be tossed out with other old but necessary techniques—definitely not in the interest of either the project or the organization.

[i] This often comes from past experience and is one of the reasons I’m not in favor of “neutral” scribes

[ii] This is one of my favorite scribe skills because it is essential in a requirements workshop where there’s so much happening at the same time.

[iii] louisville.edu/ideastoaction/about/criticalthinking/what for the 4 basic concepts

10 Common Problems Business Analysts Help Solve

Written by Esta Lessing on July 27, 2022. Posted in Articles.

Often Business Analysts are swept up by the hustle and bustle of project life and simply do what is needed to get to the end goal. Business Analysts focus on delivering a valuable solution to business stakeholders and they forget just how much value they add by help solving many problems along the way.

This short article outlines 10 of the common problems that Business Analysts help solve in the organization and especially when helping to deliver progressive change initiatives for the organization.

In no specific order of importance, find out more about these common problems that Business Analysts help solve and see if you can recognize some as familiar problems you often help solve too:

#1 Unclear or conflicting stakeholder expectations

Stakeholders may have unclear or conflicting expectations of what a project will deliver which hampers progress and can lead to disappointment.

Business analysts can help mitigate this problem is to ensure that all stakeholders have a shared understanding of what is achievable and what the project will deliver.

A Business Analyst helps to solve this problem by facilitating workshops with stakeholders to reach agreement on project outcomes, and by creating clear documentation of requirements that can be referred to throughout the project.

#2 Inadequate resources

Many projects also suffer from inadequate resources these days, which can lead to delays and frustration. Experienced Business Analysts can help identify which skillsets are needed to help deliver a project during the planning stages of the project to ensure resources are request early during the project set up stages.

Some more ways that a Business Analyst helps to solve this problem is by monitoring project progress and highlighting to the Project Manager where risks of resource shortages may occur. Where possible Business Analysts also help to create mitigating actions to avoid potential project delays due to resource constraints.

#3 Poor communication

Poor communication is often a root cause of many problems that occur during a project. Miscommunication can lead to misunderstandings, errors, and delays.

A Business Analyst can help to improve communication by facilitating communication between stakeholders, creating clear and concise documentation, and holding regular meetings to update everyone on the project status.

#4 Unclear or changing requirements

Unclear or changing requirements are one of the most common problems faced by Business Analysts. This can cause confusion amongst team members, as well as delays in completing the project.

One way that a business analyst can help solve or minimize this problem within a project is to ensure that requirements are well-defined and agreed upon by all stakeholders before work begins, whether they are working in Waterfall projects or Agile based iterations. This can be done through creating a requirements document which outlines all the requirements for the project and getting sign-off from relevant stakeholders.

In an Agile environment, the Business Analyst can help manage this issue by ensuring that user stories are well-defined and understood by all team members before work begins on them.

#5 Lack of engagement from stakeholder

Another common problem faced by Business Analysts is lack of engagement from stakeholders. This can be due to several reasons, such as stakeholders being too busy, or not feeling invested in the project or even mistrust of the business analyst.

The Business Analyst can solve this by ensuring a clear stakeholder engagement plan is a key activity within the project. The Business Analyst can also work to build relationships with stakeholders and ensure that they are kept updated on the project status and progress.

#6 Ineffective or missing processes

Ineffective or missing processes can lead to a number of problems within a project, such as errors, delays and duplication of work. This is often due to a lack of understanding of current processes being followed within the area the project is trying to solve for.

A way that the Business Analyst can help to solve this problem is by conducting a business process analysis to understand the current processes in place and identify areas for improvement. The Business Analyst can also work with the relevant stakeholders to develop new or improved processes where needed.

#7 Lack of understanding of user needs

A very common problem that a Business Analyst face is a lack of understanding of user needs. This is not because the Business Analyst is ineffective when engaging stakeholders necessarily, it can be due to several reasons including unavailability of key stakeholders and time or resource constraints that exist within the organization.

If there is a lack of understanding of user needs, it can lead to the development of a solution that does not meet the needs of the users, and ultimately will not be successful.

The Business Analyst can help to solve this problem by conducting user research and requirements elicitation to understand the needs of the users that will be using the solution. This can be done through a few methods such as interviews, focus groups, workshops or surveys.

#8 Lack of understanding of business goals

Many business analysts also find that there is a lack of understanding of business goals within an organization. This can make it difficult to align projects with organizational objectives and ensure that the right solutions are delivered. Often a Business Analyst will be assigned the task of developing a business case for a potential solution without having clear alignment of business objectives.

A way the Business Analyst can help to establish a clear understanding of the business goals is to work with stakeholders to document the business goals and objectives for the project. This can be done through workshops or interviews to understand the pain points that the organization is experiencing, and what they are looking to achieve by undertaking the project.

#9 Change fatigue

Another common yet less tangible problem faced in organizations is change fatigue. This is when staff members become resistant to change because change happens so frequently within the organizational area. This situation can make it difficult for Business Analysts who has to introduce new changes to business stakeholders and it becomes hard for Business Analysts to achieve their requirement outcomes.

One strategy a Business Analyst can follow to help manage the change fatigue of their stakeholders is to ensure that they keep them updated and engaged at the appropriate level throughout the project. They should at the same time aim to champion the benefits of the change to stakeholders and try to avoid asking stakeholders to repeat requirements or information that may have been articulated in the recent past by other Business Analysts. This is where it is very useful if Business Analysts can research similar project information to avoid rehashing the same content with fatigued stakeholders.

#10 Lack of governance

Finally, another common problem faced by Business Analysts is a lack of governance around requirements management. This can lead to several issues such as scope creep, requirements changes being made without consent or approval, and a general lack of control over the requirements. This can be a particular problem on larger projects where there are many stakeholders involved and the Business Analyst is not the only person working on gathering and documenting requirements.

A way to help solve this problem is for the Business Analyst to put in place a requirements management governance framework. This should include processes and procedures for how requirements will be managed, approved, and changed throughout the project. It is also important to ensure that all stakeholders are aware of and agree to the governance framework prior to the start of the project.

Conclusion

These are some of the top problems I could think of that Business Analysts often face and help solve. Some projects have multiple of these challenges happening at the same time which makes the role of the Business analyst very valuable as problem solver.

Best of BATimes: How To Level Up Your Business Analyst Career

Written by Shanif Dhanani on July 6, 2022. Posted in Articles.

As a forward-thinking Business Analyst, this question is probably crossing your mind frequently.

You’ve established yourself in your career, but you may feel stagnant, eager for a change of scenery or simply ready to learn something new. In a competitive job market, Business Analysts need career know-how to navigate their next steps to keep their work fulfilling. Read on for simple steps you can take to take your Business Analyst career to the next level.

Understand Which Career Path You Want

To get an edge on advancing your career, you need to know where you want to end up. Business Analysts can take their careers in any one of a variety of directions. It all depends on your interests, strengths and opportunities.

As you move through your career, you’ll see that job titles and descriptions become more specialized and specific based on industry and skills. If you’re interested in the tech industry and you’re good at bridging technical work with communicating specialized ideas, a role as an IT Business Analyst could be a great fit. If you’d prefer to work in a variety of industries doing C-level consulting, you may consider a path into a Management Analyst position.

These are just a couple of examples of advanced and in-demand career paths for Business Analysts. Collabera and New Horizons Computer Learning Centers have detailed descriptions of directions that Business Analysts may take as they move throughout their careers.

Find A Mentor

A mentor is a great industry-specific resource for everything from day-to-day questions to giving insight into career decisions. Mentor-mentee relationships can begin organically, like with a trusted superior at work, or you can seek one out with a networking program. The International Institute of Business Analysts (IIBA) hosts local chapters where you can meet other analysts at different points in their careers, and they are forming a mentorship program for members.

A mentor should be someone you can see regularly, perhaps daily or weekly, and who can get to know you and your work habits well. Ideally your mentor is someone at your company, but a former colleague or even a professor can make a great mentor too. With a mentor, you’ll form an ongoing bond that will evolve as your career goals change.

Get A Career Coach

While mentors are typically fellow Business Analysts, career coaches are professionals who operate from a higher level as they help you seek out new opportunities. They may not be Business Analysts themselves, like a mentor would be, but they have plentiful resources for networking, optimizing your soft skills, and helping with resumes and cover letters.

Career coaches often focus on a local region where they have expertise on the job market. They meet with their clients for sessions lasting up to a couple of hours for a flat fee. Virtual and nationwide services are also available through organizations like TheMuse. If you plan on meeting with a career coach, make sure you have an idea of what you want to accomplish during your session and have documents like your resume and work history handy.

Take Classes

Your experience as a Business Analyst doesn’t have to come solely from formal education or on-the-job projects. Taking classes allows you to improve existing skills or add new skills to your resume through cheap and accessible means.

Business Analyst networking groups, like the IIBA, hold specialized workshops to help you hone your skills and learn from other Business Analysts. If you prefer self-directed learning, there are free online resources with high-quality trainings for Business Analysts, like LinkedIn Learning, where you can earn certificates to display on your profile. Coursera also has a free curriculum that specializes in business analytics with courses designed by The Wharton School of the University of Pennsylvania. These courses are great if you have a specialty field in mind where you may be lacking competencies.

Volunteer For Challenging Projects

If you feel stagnated in your current role, be on the lookout for opportunities to challenge yourself. Offer your input in projects that may be out of your usual comfort zone so that you can learn with skilled colleagues or step forward to tackle an issue you found in day-to-day processes. No matter the project, be sure to ask for help when you need it—that’s one of the best ways to grasp new concepts and skills. By taking on challenging projects, you’ll not only gain experience, but you’ll also establish yourself as someone who takes initiative.

Invest In Soft Skills

While it makes sense to devote your time to expanding your technical skills, don’t let soft skills fall by the wayside. Soft skills are qualities and interpersonal skills that are less “trainable” than hard skills, but translate to every role in every industry. Soft skills include conflict resolution, negotiation, communication skills and more. Usman Haq details important soft skills for Business Analysts in his article in BATimes. These skills are acquired and practiced daily, so be mindful of opportunities to hone them. LinkedIn Learning also has courses on soft skills so you can study at your leisure.

Are You Ready To Take Your Career To The Next Level?

Being a business analyst entails wearing a lot of hats. Conquer your career path by understanding your long term career goals, find a mentor and a career coach to help you reach those goals, take classes for both hard and soft skills and don’t be afraid to raise your hand for big projects. As you take these small steps, your future in Business Analytics will unfold.