Skip to main content

Tag: Best Practices

BATimes_July05_2023

Be Bold: If You Disagree, Leave Them In No Doubt

Very early in my career, I was probably a bit too much of a ‘people pleaser’ which led to me shying away from conflict.  It’s a common trait in BAs, we want to help people out, and we want to get them the best possible outcomes. This is a positive thing, but when over-played it can spill over into conflict avoidance, and this really isn’t a good thing.

 

For example, imagine a stakeholder requests a new feature, but there’s clearly no time or budget for it. It would be very easy to say something along the lines of:

“Ah, yes, that’s really interesting. I’ll see if that’s possible and come back to you if it is”

 

Now, on the face of it no commitment has been made, the BA might consider they’ve said “no”, but it’s a very, very weak no. The stakeholder may well have heard things differently, and might have drawn the conclusion that the feature will be delivered, after all, they didn’t hear the word ‘no’ at all!  In three months’ time, when memories have faded, they may well ask you why the feature they asked for still isn’t delivered…

 

Conflict Avoidance Isn’t Friendly

Avoiding conflict might seem like a good tactic, but it really only works in the short term. When disagreement is communicated in a subtle way, it’s easy for there to be a sort of illusory agreement. Stakeholder A disagrees with Stakeholder B but they think they are agreeing. Of course, eventually they’ll find out that they didn’t agree… but by that time budget and time may have been spent unnecessarily.

 

This is an area where BAs can add huge value. Firstly, by being bold and concisely stating when something is outside of scope or can’t be delivered in a particular timeframe. This doesn’t mean it can’t be delivered… it just means that a conscious choice needs to be made. There might be a trade-off, by having feature X, it means that feature Y will be delayed or discarded. Or perhaps it means that there needs to be a discussion over the budget.

 

All of these decisions are best made consciously. A little bit of discomfort now, followed by an honest and transparent conversation is likely better than taking the easy route and saving up the consequences for later. You might be familiar with the concept of technical debt… well this is similar, it is almost a form of decision and conversational debt. By having illusory agreement over things, the decision is never really made, and an absence of decision creates issues.

 

Cultural Dimensions

Of course, it’s important to take national culture and corporate culture into account when considering how to respond to conflict.  I can only speak as someone who has spent most of their time in the UK. I certainly know that in the UK we are fairly indirect communicators at the best of time (“Oh I’m very thirsty” can be code for “I’d like a drink please, but I can’t ask directly because that would be seen as impolite”. Equally “Hmm.. .interesting” can sometimes mean “I have zero interest in what you are saying”. We are a complicated nation!).

 

There are certainly other cultures where different types of response will be more appropriate, so it is all very much down to the context.  One thing that is common though is conflict is best negotiated openly and honestly, and pretending it doesn’t exist is unlikely to lead to the best possible results.

 

Advertisement

 

Conflict Doesn’t Have To Be Negative

There is perhaps a view that conflict is inherently negative, yet that doesn’t have to be the case. Often conflict arises because different people have different backgrounds and perspectives. As BAs, we can explore those perspectives and understand the specific areas where they agree and disagree. We can work with them to navigate the conflict, and reach a situation that they are happy with.

 

In many ways, if there are conflicting views, it is usually better if they are surfaced earlier rather than later. If someone disagrees but doesn’t feel able to raise the issue, then this may indicate that they feel uncomfortable. Perhaps psychological safety is lacking. Either way, this may indicate wider issues with the organizational culture, and may mean that dissenting voices are being quashed. Which can be an issue if one (or many) of those voices are right!

 

Lead by Example

This is an area where BAs can lead by example, by being bold and sometimes vulnerable, by asking ‘tricky’ questions and being open and honest when we think something isn’t right. It’s also important to be prepared to change our minds when new information presents itself. All of this relies on building good rapport with stakeholders, which is a key BA skill in itself!

BATimes_Jun29_2023

The Importance of Benefits Realization

As a business analyst you are not done your job after the deployment of the solution. Although, having the solution up and running is a critical milestone it’s not time to party yet.  It’s like medical surgery. Even though the surgery itself may be successful it is more than important the patients life to be improved and the expected benefits that are the answer to why this surgery should be done, to be realized after the surgery.

Monitoring the solution benefits and interpreting thoughtfully the feedback of the customers is crucial in order to be sure that the benefits of the solution are fully perceived and also that they are sustained. Benefit recipients should experience the stated benefits and also be ensured that those benefits will be sustained from the implemented change over the long-term. In many projects the effort that is done in the period after implementation activities is not enough to ensure the delivery of the claimed benefits as well as the maintenance of the benefits in the long term.

 

Advertisement

 

Below are some points that could help you navigate in the after-deployment period:

 

  1. Feel the pulse of the customer

Be open to feedback and try to listen to the voice of the customers. Do not underestimate the feedback from any source. Even an inexperienced user may reveal critical improvement issues for the benefits realization. Filter the feedback in order to find technical and non-technical groups of issues. For example, a repeated concern of the user may be due to the lack of training and proper user manual, due to a non-functional requirement that is not met or due to a bug existing in the functional area of the solution. 

 

  1. Prioritize the actions

It is crucial to prioritize the improvement actions. Some bugs fixing may be in first priority as they have a detrimental effect in the overall experience. Or an updated user manual and video of navigating the users in using effectively the solution may be number one priority in order to full realization of benefits to take place. A specific prioritization approach may be existing and agreed up at the initiation of the project. However, as nothing is more stable than change you probably need to revisit and update frequently the approach to prioritization.

 

  1. Be ready for Organizational Change

A new solution that is deployed is a change. Appropriate change management is required to ensure the full exploitation of the solution. New processes and polices may need to be established in order to maximize the value. Changing the way of working that existed for years may be challenging. Many times, a new solution is a trigger for a culture shift in an organization. As a business analyst you need to be aware of such required changes and propose solutions that will contribute towards the

 

It is common for the delivery team to complete the implementation activities, deliver the initial benefits to the customer and just close down the project. This is not suggested. Benefits realization most of the time is not one and done process. There are always activities that need to be performed on an ongoing basis to ensure the solution developed stays in shape.

BATimes_Jun15_2023

Ten Tips for the Young BA

After ten plus years of working as a business analyst, I wanted to highlight a few things that have tremendously helped me become a better BA and advance my career.

As a young professional, I did not have many special talents, skills, or academic education, but I was not going to let those things hold me back from success. I focused on where I knew I would stand out and organized my thoughts into the ten main points below:

 

  • Be on time. For any meetings or working sessions that I was a part of, I made it a habit to be a couple of minutes early. There were life events or uncontrollable circumstances that prevented me from this 100% of the time, but those were one-off occurrences. Generally speaking, I was known to be early and start meetings on time. This showed I was organized and respected the time of others. Additionally, being on time also meant projects and tasks were completed by the time I said they would be. If there were issues that prevented me from hitting a time goal, I would speak up and inform the respective stakeholders in advance so they were aware.

 

  • Take ownership. Anytime a project or task was assigned to me, nobody had to worry or consistently follow up on its completion. I communicated statuses and any obstacles or issues that might impact the final result. This was evident no matter how small the task was. Early on in my career, I was responsible for member service requests. Each interaction was a mini-project to ensure the member got the service they required. Taking ownership of all of my projects and tasks helped build trust with my boss and colleagues. It showed I was ready to handle larger projects and more responsibilities because I excelled with the smaller ones.

 

  • Be flexible. My ability to be flexible about almost anything shined through. My role in one project may not have been the exact same as another one. Priorities and objectives often changed. My colleagues all had different and unique personalities. In some projects, I was the dominant personality when others did not play that role. In other projects, I was the more analytical one when I realized others were observably dominant. Through it all, I remained flexible. I was known as the go-to person for just about anything.

 

  • Nothing underneath me. My first project was a stepping stone to the next one. When I was starting my career, I admittedly was a “yes” person. They could have given me a stamp with “Yes” for my forehead! Before anyone even finished their thought, I said “Yes!”. This helped me get exposure to every single area of my organization and build relationships. Within a short period of time, I could tell you the purpose of each department and why they were necessary for the organization to function properly. I am not saying I could run the department, but I had functional knowledge of their work and what made them tick. I don’t want to give the wrong impression here. As I advanced more in my career, I didn’t have the time to say yes to everything. I learned how to say “no” as my career became more mature. However, when I first started, I wanted exposure to everything and I wanted to show I can handle it.

 

  • Recognize and praise others. I don’t remember accomplishing a goal due to my efforts alone. There were always other people involved. Lots of time in discussions was spent with team members to ensure we were doing the right things. I always made it a point to praise publicly and privately where it was legitimately due. I saw first hand all the hard work that my colleagues put into their daily activities and wanted those efforts recognized. Any time I got praise for doing something, it was only because I had a great team of people supporting me.

 

Advertisement

 

  • My first project. I tried my best to stay excited and eager to learn and do more. When I was just a part-time employee trying to make a name for myself, I was hungry for anything that came across my desk. I started to treat everything like my very first project. I would ask lots of questions, show willingness to go above and beyond, seek help where I need it, and work with others. Every project after the first one was treated like my first one. This is much more difficult than it sounds because at times, work did become mundane and repetitive. I had to make a conscious effort to see the bigger picture and maintain my level of excitement.

 

  • Open to criticism. I had an open mind if someone gave me constructive criticism. This helped me get better as a professional and build my skills. I actively sought out criticism to ensure I produced things of value to the organization. Long tenured employees, managers, and executives all have different insights into different areas. Their advice helped me see things from a different perspective and ensure I took that into consideration moving forward.

 

  • Be courteous. I cannot think of any point where insulting someone, yelling, making sexually suggestive comments, touching inappropriately, or being plain rude was ever welcomed. I paid attention to my tone of voice and ensured my dialogue was objective to the matter at hand. Disagreements are common and objectively addressing them should be the goal, not trying to tear the other person down. Learning about culture, gender, age, race, religion, or any other characteristic that makes us unique, helped me get to the next level of relationship building. Showing common courtesy, being generally kind, and showing basic respect for someone  should not require a whole training initiative.

 

  • Work life integration. I did not seek work life “balance”; where I strictly worked between certain hours and then I strictly lived my personal life during certain hours. My job was part of an overall healthy life; and in order to continue having a healthy life, I needed my job. Sometimes, my best work came from putting in a few hours on a Sunday with some music in the background. Sometimes, I had to handle a personal emergency at the office that took time away from my work. I didn’t get stressed out about those things because I knew the work would get finished and my personal commitments wouldn’t be sacrificed. If responding to an email on a Saturday helped my colleague move on, I did not hesitate to do it.

 

  •  Always learning. I was always confident I could learn anything that I needed to help in my career. Today, I see the younger generation spend hours upon hours on social media, video games, and YouTube. I challenge anyone to take any topic in the world you want to learn. Spend one to two hours daily focusing on and researching that topic. The same focus you would give to having fun. Come back in a year and tell me that you are unable to explain the general and functional information of that topic. I dare you! I was amazed at how much I learned by giving it enough focus and time and you will be too.

 

In conclusion, these ten things made such a positive impact in my career and I know they will do the same for you.

BATimes_Jun14_2023

Working Well with your Test Team

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?

 

Advertisement

 

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.

 

 

BATimes_Jun1_2023

Use Case or User Story

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.

 

Advertisement

 

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.