Tag: Methodologies

Working Well with your Test Team

Written by Virginie Terry on June 14, 2023. Posted in Articles.

Business Analysts and Testers are the two cornerstones of software projects delivery. The BAs define the business needs, they validate solution options, and they remain present throughout the project delivery to ensure the project’s objectives are met.

The Testers’ role is to ensure that the solution does operate in the way that it has been specified before it is implemented: they verify that there are no defects, and that the users can achieve their outcomes without introducing new risks or issues into the organisation.

Is there anything you could do to enhance the collaboration between these two teams in your organisation?

Clarify your own understanding of the work the Testers do

Does your Business Analysis Team understand the complexity of testing, or is it an amorphous phase they have no real interest in? Do they appreciate that the test plan will vary depending on the nature of the solution? Do your BAs understand the Test Team’s structure, the tools and templates they use, their dependencies, or how they test non-functional requirements (NFRs)?

Awareness of their operational model and what’s important to them is hugely beneficial to understand the types of pressure they face and how the Business Analysis Team fits into it all.

Conversely, make sure that the Testers know how your team operates

The Test Team may not appreciate the challenges that you face on every project to agree the scope – the back and forth with senior stakeholders who can be reluctant to sign off. They may not realise the importance of some of the documentation that you produce, or why it takes so long to get it right.

Taking the time to explain how your team operates will increase the Testers’ appreciation of your skills and avoid misunderstandings or assumptions on the execution of your work, particularly when it feeds into their own deliverables.

Avoid functional silos

Avoid the “them and us” culture, which can be a real barrier to success. Functional silos become particularly problematic when the project team is under pressure, for example if the delivery isn’t on track. They can easily create an unhealthy tension within the project team.

An effective counter to this is to collaborate and involve your Tester(s) early into, and throughout, your analysis work. Make them aware of what you’re working on before the business case is approved. Give them an opportunity to review your requirements and feed into them before they are signed off. Walk them through the business processes so they understand the intentions behind the new system.

Not only will their feedback improve the quality of your analysis work, but it will also deliver a myriad of efficiencies during the project delivery, from the Test Team resource allocation planning to the ability to produce an early strawman of the Test Plan, for example.

Listen to the Test Team’s feedback

Recognise that sometimes the BAs’ work can fall short of quality expectations and address these issues appropriately, whether individually or at team level. Is there an unusually high number of change requests on all projects from a particular BA for example, in which case they may need some coaching on their requirements engineering skills? Or should you consider new standards or templates, or maybe even some team training, if common analysis problems are emerging across multiple projects?

Be very clear about your role on the project

Let the Tester(s) know how you are working through any issues, particularly if they are not of your own making, to avoid any misunderstandings about the quality of your work. In extreme but not uncommon cases, the solution is agreed, and a new system purchased, without a clear definition of the business need or other systems it may need to integrate with.

On these projects, your role as a BA is to retrospectively write the requirements, and unfortunately, you’ll need to battle with business users throughout the analysis and design stages to justify the scope, particularly the elements that the new system doesn’t support but they would like to have. It’s not insurmountable, and you will likely come up with viable manual workarounds.

It’s important for the Testers to be aware of this history so that the Testing phase, and specifically user acceptance testing (UAT) can be managed effectively, as these contentious, out of scope items, may be raised as bugs by users in UAT.

Conclusion

Business Analysts and Testers work together to guarantee that solutions are fit for purpose. With mutual respect and an appreciation of each other’s work, the teams should naturally be able to collaborate effectively and work through the challenges of the project delivery.

This doesn’t mean that the two teams will always agree on the best option to resolve them, but they will understand each other’s perspective and be more inclined to compromise or make concessions where they are necessary and possible.

Use Case or User Story

Written by Steve Farrall on June 1, 2023. Posted in Articles.

An interesting question! Do we stick with use cases or switch to agile user stories as the best way to model, understand and deliver requirements?

The answer is to apply both techniques and together they work well to complement each other. In this approach, I view the use case as a business use case focused on business actions and processes; the user story is focused on the system requirements elaborating what is required of the system to support the business use case and supporting the agile sprint development process.

Use Cases

The objective of the use case in this context is to communicate the understanding of the requirement to the SMEs and stakeholders to ensure that the correct solution will be developed. It won’t be fool proof, but it should help steer the development in the right direction; until the first show and tell session, you can never be absolutely sure the requirement has been fully understood.

I would restrict the use case content to be only that essential to explain how the requirement will be delivered; alternate flows etc should be pushed into the use stories as far as possible. It may well be useful to expose some draft business rules for discussion as part of the use case but keep in mind the rules will need to be included and implemented via the user stories.

The Tool

We had already setup a wiki using the Atlassian Confluence tool, the logical step was to extend the existing wiki and introduce a fairly simple template for our use case pages; different tools could be adopted, even PowerPoint would work. Using Confluence allowed existing content to be linked directly into our use case pages as needed; it also includes a presentation mode allowing page content to be used directly in a presentation and exported to PDF or Word format documents.

The use cases can then be used to present back to the SMEs and stakeholders to confirm the understanding of requirements and the validity of the proposed process.

Tip – Catalogue Use Cases

It is useful to have index of all the use cases that includes a status to show work in progress, which ones have been published and those reviewed with SMEs. We managed our use case catalogue within Confluence using custom decision pages to provide an index view of all the cases.

User Stories

The key differentiator with the story is that it targets a specific system requirement and product feature, explaining a feature to an SME is a valid activity but without the context of the overall process, it might be a hard sell. Typically, you will need to introduce some supporting product features which may not be immediately obvious to SMEs; hence combining the stories together into a coherent business process will help SMEs to understand the overall solution context.

User stories can be identified but not elaborated depending on the level of confidence in understanding for a given requirement and business process. It may be appropriate to propose a change based on the understanding prior to a workshop or it might be better to get feedback from the workshop and then work on the stories with the knowledge gained.

The objective is to gain confidence in the understanding of a requirement so that everything can proceed down the right track with a joined-up set of product features.

Tip – Catalogue User Stories

A template for developing user stories can be adopted, this is useful as a prompt for details which may be appropriate e.g., what’s the existing feature doing currently and what needs to be changed. We managed our use story catalogue within Confluence using custom decision pages to provide and index view.

Joined Up Thinking

Use cases and user stories come together in the steps of a use case i.e., supporting the flow, whether it is worth elaborating main flows and alternate flows within a single business use case is debatable. The key objective is to keep the use case as simple as possible whilst demonstrating how the requirement will be met, so adding exception flows may cause confusion at this stage.

It is also possible that an existing feature will support a requirement without the need for a change story to be introduced; it is valid to include this feature in the use case as a step to demonstrate how this will work. For an existing feature, screen shots can be included and marked up with candidate changes; for a new feature then a wireframe mock-up may be included where a user interface is needed to support a step in the process.

Tip – Catalogue Use Cases

It will be useful to have index of all the use cases that includes a status to show which ones have been published and review with SMEs. We managed our use case catalogue within Confluence using custom decision pages to provide and index view.

Requirements and Use Cases

Now we are starting to build up a comprehensive set of product features that will meet the requirements and these will have been validated with SMEs; so, we are in a good position to elaborate the details of the user stories that will be needed to change existing features and add new features to the product.

Tip – Link Requirements

Linking requirements to use cases is a useful way to file the information, not all requirements will need separate use cases only those where confirmation is needed to better understand the underlying business need which can sometimes be obscured by a badly written requirement.

Conclusion

The use case is the glue that binds the product features and stories together into a comprehensive system that will meet the stated requirements; the user stories allow this requirement to be broken down into manageable features for delivery by agile sprint development teams.

Best of BATimes: 10 Best Business Analysis Books For Beginners

Written by Theresa Cofield on May 18, 2023. Posted in Articles.

Corporate analysis is a discipline in which business requirements are defined, and solutions are identified for business issues.

For an organization to thrive and function successfully, some things need to be placed during its foundation. Here are some books that can be of assistance.

1. Writing Effective Use Cases (Agile Software Development Series) by Alistair Cockburn

Business analysts profit from case studies where they talk about how people use a system. This helps in planning projects and use cases is a crucial feature of business and software systems. The problem is that it is not so easy to write straightforward and succinct cases. Author Alistair Cockburn utilizes modern methods to write case stories in this novel.

You can learn about advanced principles that are useful, whether you are an experienced analyst or a novice. Cockburn presents strong and bad case examples to help you quickly and rapidly understand the difference. The main aspects of situations, like stakeholders, scenarios, etc. Design, moment tips, pre-built templates can be utilized.

2. Business Analysis Techniques: 72 Essential Tools for Success by James Cadle

Every analyst needs the necessary resources to accomplish the job. The work involves solving problems and exploring ideas. You need to know how to solve various types of problems, like identifying project specifications or handling changes.

This book describes these strategies carefully in order to help the reader deliver reliable results in business work. Think about it as a market analyst, a manager, or a student who is learning the trade, as a cheat sheet you can talk about.

3. Project Management Absolute Beginner’s Guide (3rd Edition) by Greg Horine

You have just started working as a project manager? In this book, you can easily and rapidly grasp key concepts by disrupting vital project management activities. You can learn how to organize and manage budgeting, planning, team management, and more. Each phase is outlined so that you can start right away.

The guidelines are simple and convenient. You will discover that the project managers make daily errors to avoid taking the same route. You can also understand what heading projects entail instead of merely overseeing them. If you do not know how to begin your job or your career, take this book to learn what you need quickly.

4. Project Management: A Systems Approach to Planning, Scheduling, and Controlling by Harold Kerzner

This is referred to as the Project Management Bible” since it offers practical insight into all facets of becoming a project manager. At all levels of a project, you can learn the techniques and methods to use. But it’s more than tips in this book. This text covers market changes, failure, agile project development, evolving industry topics, and project measurements.

There are just a few components that can limit performance in project management. This book is not a guide to project management, which is easy. There are plenty out there. When you want to know information about project management, quality assurance, and customer cooperation, this is the book you need to collect.

5. Business Analysis for Dummies by Kate McGoey, Kupe Kupersmith, and Paul Mulvey

Business Analysis (BA) is a group of activities that ensures that the company has the best solutions to achieve its strategic objectives. In order to carry out this workforce, it is important first to define the actual objectives and evaluate and propose solutions for a solution that needs to be addressed.

Provide guidelines as to how the market analysis will influence your company. Shows the tools and strategies to be a competent analyst. Provides many examples of how to market evaluations can be carried out irrespective of your position.

6. Adaptive BABoK Study Guide by the Adaptive US

BABOK® summary graphically represented to enable simple, engaging learning of concepts and practices of business analysis. However, a visual presentation and a summary of this information are effective for you to learn. BABOK® guide includes a large amount of structured text information.

7. 3D Business Analyst by Mohamed Elgendy

Three distinct fields of 3D Market Analysis – business analyzes, project management (PM), and lean 6 sigma – with historically different skills and career paths. When, however, the components of these skill sets are analyzed and understood, a simple overlap is generated. When used together, they provide the BA with the required concepts, theories, and ends so that it can interact more effectively with stakeholders in its own language.

8. Agile and Business Analysis: Practical Guidance for IT Professionals by Debra Paul and Lynda Girvan

Agile is an iterative approach to software development that has quickly become the most common replacement for conventional project management in the IT industry. The use of an agile approach will revolutionize work practices for business analysts. It allows for a clearer vision and definition of performance steps, greater participation of stakeholders, and a better understanding of consumers.

This book offers an extensive introduction and discusses Agile methodologies in the sense of market analysis—ideal for companies wishing to learn and understand Agile Practices in an Agile Environment.

9. Business Analysis: Best Practices for Success by Steven Blais

A full overview of the business analysis method in addressing business issues is given by this book. This guide is also full of real-world stores from the author’s more than 30 years of experience working as a market analyst, full of tips, tricks, methods, and guerrilla tactics that allow the entire process to face often daunting political or social obstacles.

It offers strategies and advice to conduct a business analyst’s challenging tasks at times.
Authored by a professional in the sector with 30 years of experience.

10. Seven Steps to Mastering Business Analysis by Barbara A. Carkenord

Business analyzes are now the fastest growing sector in business and both strategically and tactically the position of the business analyses. Seven steps to mastering business analysis illustrate how all these variables, along with many others, are the secret to success.

This book offers insight into the ideal skills and features of good market analysts and is the basis for the learning process. This guide also allows you to prepare for enterprise analysis certification by describing the tasks and fields of expertise in the Knowledge Body.

Conclusion

Businesses form an important part of a state. Encouraging young people to venture into business only increases employment opportunities. Through business books, this becomes an attainable goal as they offset with their best foot forward.

Published on December 3, 2020.

Best of BATimes: 7 Warning Signs that You Are Too Soft

Written by Neal Whitten,PMP on May 17, 2023. Posted in Articles.

Simple question: Do you believe that you tend to be too soft at work?

What I mean by too soft is demonstrating behavior that results in being consistently less effective than what is otherwise possible—and needed—in performing responsibilities.

Whenever I ask this question at conferences, seminars or webinars, most people respond with a “yes.” From experience, I have found most project managers and business analysts, indeed, to be too soft—they are not willing to make the tough and unpopular project- or business analyst-related decisions, even though their instincts warn them that they are not taking the most effective action.

Being too soft harms your effectiveness, your career, the respect from others and your ability to make a difference and make things happen.

Examples of Too-Soft Behavior

Here are seven examples of too-soft behavior. Do you see yourself here? If so, this article may cause you to leave your comfort zone.

1. You behave as if you have the responsibility but without the authority

If you behave as if you have the responsibility but without the authority, then you’re too soft. I do face time with thousands of people each year. I frequently hear project managers and business analysts say that they have the responsibility but not the authority. This just isn’t true. You almost always have the authority; the problem is that you don’t take it.

Here’s an example. When was the last time you were called on the carpet—challenged—for exceeding your authority? Was it within the last week? The last month? The last year? Was it ever? My experience is that less than 15% of people in a large group—a statistically valid size group—have ever experienced being confronted for exceeding their authority. This is sad to me. But what is sadder is that, statistically, most people reading this article will never experience being called out on exceeding their authority across their entire career! My assertion is that you almost always have the authority—you just don’t seize it… you’re too soft.

2. You put off insisting on and driving good project management or business analyst practices

Whether I’m in a public setting or at a private company, it’s common for PMs or BAs to approach me for advice about their project problems. During the discussion, many times it’s relevant for me to ask about the project management or BA practices that they follow. I often hear them say that the practices they follow are weak and insufficient. They will state or imply that management in their organizations isn’t doing enough to provide and continuously improve the practices.

I’ll ask them what their role on the project is and they will tell me that they are the PM or a BA. If you are in either of these roles, then insisting on and driving good practices is your job. Not management’s. Not anybody else’s. It’s your domain of responsibility. You can seek help if you need to but the buck stops with you. If you do not insist on reasonable practices then you’re too soft.

3. You complain rather than constructively work issues to closure

I don’t believe that you should ever complain about anything—ever! Complaining is negative energy and adds no value to solving the issue at hand. People who complain are exhibiting too-soft behavior by averting truly getting the problem fixed. But make sure you understand what I mean by complaining. An example of complaining is when person A complains to person B about something that person C can fix. In this case, person A just wasted his time and person’s B’s time. However, if person A “complains” so-to-speak to person C—the person who can fix the problem—then this is not complaining to me. This is the first step of the solution by informing the person who can do something about it.

4. You evade taking a position on issues

If you evade taking a position on an issue, you’re too soft. A role of leaders is to help resolve conflict among team members. They take appropriate business-based positions on issues even if it doesn’t please all parties. Let’s look at an example.

I was mentoring Sarah who was a project manager of a sizeable project. We were walking through a hallway heading to a room where a meeting was soon to take place. We come upon two team leaders—Laura and Larry—discussing an issue in the hallway. Actually, discussing is too kind of description; they were angry at each other and loudly protesting the other’s views. Upon seeing this, Sarah leaned in to me and asked if I would mind if we join in on their discussion. Sarah said we have a few minutes before we must be in the meeting room. I said that that’s a good idea and we joined the two team leaders. After standing with the two team leaders and listening for a few minutes, Sarah turns to me and said we have to go; she did not want to be late for the meeting.

Once we were out of hearing range of the two team leaders, I asked Sarah why she didn’t say anything back there to help resolve the conflict. Sarah said if she had sided with one team leader then the other team leader would have been upset with her. I said that’s not how it works. Besides you now have both people upset with you because you did not assert your authority and help find an appropriate resolution. I went on to tell her if she sided with Laura and that left Larry upset with her, that’s not her problem—it’s Larry’s problem. I said never avoid taking a position because you fear that someone won’t like you. This is business, it’s not personal. Decisions are made based on what’s in the business’ best interest; not what’s in Larry’s best interest. Here again, Sarah was too soft in dealing with this situation which meant she was not as effective as she could be and should be.

5. You avoid or excessively delay making key decisions

Decision making is a critical action in any team, project or organization. We all have experienced instances where we felt decisions were being made far too slow. Make sure that you aren’t the problem. If you avoid or excessively delay making key decisions then this is another example of demonstrating too-soft behavior.

If you wait to make a decision until all data is known to ensure that you are making the very best decision, then you will lose all competitiveness. Better to make a decision and occasionally be wrong, then make no decision or excessively delay in making the decision.

6. You fail to perform your assignment as if you own the business

When you look around you for the people who you respect the most, they are likely folks who come to work each day with the mindset that they perform their duties as if they owned the business—and the business is defined by their domain of responsibility. If you have ever owned your own company, you will know exactly what I mean. You cannot put food in your belly or pay your bills unless you are successful. It’s this passion that helps people achieve their best. These are people who make things happen.

They believe—and their actions demonstrate—that the buck stops here and that they are fully accountable for the project or their assigned domain. Your boss and your senior management want you to take charge over your domain of responsibility with the passion that comes about when you behave as if you owned the business. If you hesitate or routinely pull back then, again, you are demonstrating too-soft behavior.

7. You require the personal approval of others to function

You are too soft if you personally require the approval of those around you to function from day-to-day—and without it you feel inadequate—then you will likely find their behavior to have an immobilizing effect on you; it can stop you in your tracks. Don’t ever give that kind of power to another person. What other people think of you should never be more important than what you think of yourself.

In Closing…

I have revealed seven examples of too-soft behavior. If you routinely exhibit these too-soft behaviors, then you’re clearly too soft—you tend to take the easy way out rather than do the right thing by demonstrating the most effective behavior. If you only occasionally slip into this behavior, then that may not be a serious cause for alarm.

If you fear that not being too soft will cause you to be “too hard” and therefore you will be seen as being rude, insensitive, abrasive, arrogant or a bully… don’t go there. You are a good and decent person and will not give way to these behaviors.

You might be asking yourself if an upside of demonstrating too-soft behavior is that you might win friends and respect? After all, if you are consistently too soft, those you work with will see you as very easy to get along with and passive—you’re always rolling over and abdicating to others. The problem is that if you’re a leader and are consistently demonstrating too-soft behavior, you will lose respect from those you lead, and from your peers and from your superiors. Being too soft will also have a negative effect on your project’s outcome because the best business decisions are not always made or made in a timely manner. All this can lead to your career becoming stagnant or even shortened.

Now, go become your imagined self!

Published on February 28, 2017.

Factors Impacting Analysis

Written by Virginie Terry on May 3, 2023. Posted in Articles.

As Business Analysts, we are experts at defining good quality requirements and processes that enable the implementation of solutions which are fit for purpose and deliver the benefits from the business case. We may have several Business Analysis qualifications and many years’ experience working on all types of projects, from simple process changes to complex technical overhauls with multiple integrations, data migration and significant business change elements, and everything in between.

Yet our skills are just one of the many components that enable us to do our job well. There are some other factors which we don’t have much control over but which are also hugely important. We need to be aware of them and should consider them upfront and throughout the delivery of our projects to set ourselves up for success. Unsurprisingly, they can all be grouped under communication within project teams and organizations’ delivery standards and processes.

Consider the delivery model

Are the delivery frameworks from your organization and any third party you are working with aligned? Organizations tend to have slightly different definitions of the same terms, for example “delivery phase”. Does the delivery phase consist purely of coding and configuring what has been defined in great detail in previous, distinct analysis and design phases? Or will the delivery phase also include collaborative sessions at the start where technical teams, BAs and users flesh out these details together?

Consider roles and responsibilities

This is particularly important in organizations which have a high staff turnover, use many contractors or employ staff on short, fixed term contracts. The execution of testing can be a grey area for example, particularly User Acceptance Testing (UAT). Who is expected to write the test scripts? Is it the Tester(s) on your project, the business Subject Matter Experts (SMEs), or even yourself?

Consider the experience from other key roles within the project team

Do the Project Manager and other key roles within the project team have a good understanding of the role BAs play, what we do and don’t do? For example, do they know that BAs need to be present in all meetings with the users and technical team(s) where the scope is discussed? Or that we cannot make an on-the-spot decision about the validity of a change request, such as descoping an area of functionality because of new budget constraints, without assessing the impact on the processes and the integrity of the solution overall?

Consider the project plan

How will the project plan be produced? Do you need to do some “right to left” planning, because the go-live date can’t be moved, which is common on a lot of commercial or regulatory projects, or can you estimate the duration of each phase before agreeing on a go live date?

In the first scenario, you will need to timebox each activity and almost certainly compromise on some elements of your analysis. In both cases you need to really think through any assumptions which are being made around the effort required to produce each deliverable and any dependencies. You should also document any risks you foresee as a result of the approach being undertaken.

One common oversight is the business users’ availability to support the project, which can really hinder progress if not managed effectively. This can range from planned absence, such as annual leave, to having to perform Business As Usual (BAU) activities no one else can backfill, or supporting other projects which have a higher priority.

Consider the project governance

Does your organization have well defined processes to govern the decisions required around the different project milestones and the challenges you will meet in the course of the delivery? For example, are you clear on the documentation that you need to produce, or contribute to, at each stage gate? What is the change control process you need to follow when a new requirement emerges after the requirements catalogue has been baselined?

Consider the Sponsor’s role

Sponsor engagement, and the BA’s access to the Sponsor, are critical to the success of the project. Are you able to have one-on-one meetings where you can speak openly to update them or seek guidance when you are uncertain about the direction you should follow? Does your Sponsor know the level of involvement they need to have so that they support you, the Project Manager, and the delivery of the project, without interfering with the methodology or the due diligence required, for example?

Conclusion

There are no simple answers to these issues. Every organization has its own culture, and each project team has specific dynamics.

However, identifying them as early as possible means that you can prepare for them and address them effectively within the constraints that you operate in, even if it means you’re not able to follow best practice. When dealing with these challenges, regardless of your level of experience, you will achieve something much bigger than the delivery of your project.

This may be learning something new about the way that you communicate, educating your colleagues about the role of the Business Analyst, or even instigating an improvement in the way in which your organization delivers change.