Articles Archives - Business Analyst Articles, Webinars, Templates, Jobs

The Pitfalls Of Efficiency: Process Improvement Is A Balancing Act

Written by Adrian Reed on April 24, 2024. Posted in Articles.

Business analysis work often involves improving processes. This might include simplification of a process, reengineering or automation. When used well, IT can be used to enhance (or even completely rethink) a process. The ideal outcome is to design a process that is quicker, more convenient and more cost-effective than what it replaces.

When aiming for efficiency, it’s important to ask “for whom are we optimizing this process?”. This might sound like an odd question to ask, but often there’s a fine balancing act. A process that appears very efficient for a company might actually be very inefficient and inconvenient for its customers. Standardizing a procurement process might create internal efficiencies for the company involved, but might place additional work on the company’s suppliers.

An Example: “No Reply” Secure Email

I was recently a customer of a company that would send correspondence via secure email. I’d receive a notification via regular email, and I’d then need to log in to the company’s secure email portal to read what they had sent me. This was fine, except the emails they sent were all from a ‘no reply’ address. While the secure email system they had implemented literally had a ‘reply’ button, there was a disclaimer on every email they sent which said “don’t reply, as we won’t read what you send us” (OK, it wasn’t that blunt, but you get the idea!).

This led to the crazy situation where the only way of replying to their secure emails was to either call via phone (and queue for 45 minutes), or put a reply in the mail.

This is an example of a situation where convenience and savings are predominantly biased towards the company, with some minor benefit for the customer. Prior to sending secure email, they would put correspondence in the regular mail. Moving this to an electronic platform presumably saves in printing, postage and stamps. It’s of marginal benefit to customers too, as they receive correspondence quicker (providing they look at their email regularly).

But the real customer benefit would have been to be able to correspond and reply with the company via secure email. Ironically, by implementing the solution the way that they did I suspect their ‘no reply’ mailbox is actually full of replies from customers who didn’t read their disclaimer!

There is no “right”, it’s a balance

As a customer, I found the situation frustrating, but there is no inherent or universal ‘right’ answer here. It might be that the company in question had deliberately chosen not to accept incoming secure email for compliance reasons, or perhaps they feared they’d be flooded with lots of customer inquiries as they are now ‘too easy’ to contact (although I’d argue that if this is the case then there’s probably a bigger root cause they ought to be contending with!).

The point here is that it should be a conscious balancing act. It is all too easy to create a situation that is more efficient for one group of stakeholders, but actually worse for another. An employer who decides to streamline their process for employees who need to claim travel expenses might decide that they can save time if they ask their employees to input more data at the time they submit their claim. If they get the employee to select where the expense was incurred, the amount of sales tax that was included in the expense, the category of cost and so forth, then this saves time later. Yet an employee who isn’t a tax expert might find this frustrating (“Is train travel exempt, or zero-rated for sales tax?”). Of course, in reality this will likely affect the quality of data too, as people try their best (but don’t know which of the different tax code options to choose).

This is a specific example, but it highlights a wider point: it’s important to consider process improvements from the perspectives of the stakeholders impacted. This involves considering what efficiency as well as effectiveness looks like for each key group.

As with so much in business analysis, stakeholder identification, engagement and empathy is key!

Beyond Frameworks: Agile Insights from a BA’s Odyssey

Written by Afaq Qazi on April 18, 2024. Posted in Articles.

Reflecting on my journey from a Junior Business Analyst to a seasoned Business Analyst and eventually evolving into a role where Business Analysis and Product Management intersect, I’ve had the privilege to contribute to organizations as diverse as Boeing, Rolls-Royce, and EPAM, alongside navigating the unique challenges of smaller entities.

This path, spanning over 13 years and multiple domains, has equipped me with a deep understanding of Business Analysis from the grassroots, teaching me the crucial balance between adhering to frameworks and embracing the agility necessary for today’s dynamic business environment. This narrative is an exploration of that journey, emphasizing the transition from rigid methodologies to agile adaptability, and the critical importance of customer focus and stakeholder management.

In the early stages of my career, the allure of frameworks was undeniable. They presented a structured way of understanding Business Analysis and Product Management, offering a semblance of control and predictability in the chaotic realm of project management.

However, as I progressed, the limitations of these frameworks became increasingly apparent. The real-world application of Business Analysis goes beyond the confines of any framework. It demands an acute awareness of the shifting business landscape and the ability to think on one’s feet—a blend of deep analytical thinking and pragmatic street smarts.

This evolution in perspective was mirrored in my approach to project management. Initially, my focus was on mastering the technical aspects: understanding the ‘what’ and ‘why’ to navigate towards solutions and create value for users. Yet, I quickly learned that the essence of effective Business Analysis lies in the ability to communicate, adapt, and understand the broader business context—skills that are foundational yet flourish only with experience and deliberate practice.

Communication emerged as the cornerstone of my professional development. The capacity to engage with a diverse set of stakeholders—customers, engineers, designers, and executives—and synthesize their insights is paramount. It’s a skill that goes beyond mere articulation; it’s about understanding the audience, choosing the right words, and effectively conveying complex ideas in a manner that resonates.

This skill set has been instrumental in navigating the complexities of projects, ensuring alignment across teams, and driving towards common goals with clarity and purpose.

As I embraced the agile methodology, the importance of flexibility became glaringly evident. Agile is not just a buzzword; it’s a mindset that values adaptability, customer-centricity, and continuous improvement.

It challenged me to think differently about project management, to be more iterative in my approach, and to prioritize direct feedback loops with stakeholders and customers. This agility has been crucial in climbing the project ladder, allowing for rapid pivots and adjustments in response to new insights or changing market dynamics.

Customer focus and stakeholder management have been the bedrock of my growth as a Business Analyst. Recognizing the criticality of these aspects, I’ve dedicated myself to becoming adept at navigating the complex web of stakeholder relationships and ensuring that the voice of the customer is always at the forefront of decision-making. This has involved honing my ability to manage expectations, articulate value propositions clearly, and foster an environment of trust and collaboration.

In retrospect, the journey from adhering strictly to frameworks to adopting a more flexible, agile approach has been transformative. It has taught me that while frameworks provide valuable guidance, the essence of Business Analysis and Product Management lies in the ability to adapt, communicate effectively, and maintain a relentless focus on the customer and business objectives.

As I continue to navigate this ever-evolving landscape, these insights will remain central to my approach, guiding my decisions and actions in the pursuit of creating meaningful, impactful solutions.

4 Tips for Managing Ambiguity as a Business Analyst

Written by Giorgos Sioutzos on April 17, 2024. Posted in Articles.

As a business analyst, it is common to face ambiguity in many different forms and aspects. It may be the ambiguity of the business analysis approach you have chosen, the requirements, or the design decisions that you have to contribute to.

Ambiguity and constant changes are something that is expected. It’s up to you to respond constructively. The following tips may help:

#1- Approve Ambiguity

Although you may want to have full control over the circumstances, it will not happen. It may take time and changes in order to establish a business analysis approach to customers’ needs or understand the full aspects of the system to be developed. It is fine not to have the full picture from the beginning of the analysis journey, but it is your job to progressively clear out the context and the scope. Approve the ambiguity of the intrinsic part of the analysis.

#2- Mindset Shift

Ambiguity can cause plenty of negative thoughts and worries. Instead of entering into a negative, endless dialogue, try to view ambiguity as an opportunity for new approaches, for innovation, and for gaining experience. Ambiguity can cause team members frustration and challenges, as the situations triggering it are mostly out of our control. It is important to reframe biassed thinking patterns concerning ambiguity into positive ones.

#3- Utilizing Effective Risk Response Strategies

As a business analyst, you should cooperate with the project manager to recognize factors and assumptions that can affect the business analysis objectives. You have to understand the sources of the risk and craft alternatives you can use if those risks actually occur. Whether you are a lead business analyst or other team member, your ability to identify and respond to risks effectively will affect the team’s ability to successfully complete project tasks.

#4 – Have a Compass

Having a specific compass for ambiguous situations is essential to guiding your decisions and actions. Orienting yourself and leading your team through a period of ambiguity can be supported by a stable and valuable foundation of personal and organizational vision, mission goals, and objectives. Knowing at any time why you are doing something and what you want to achieve and being true to yourself and your team can guide you as the North Stare in unpredictable and chaotic situations.

By viewing ambiguity as an opportunity, you can reduce the stress imposed by an ambiguous situation, experiment with new processes and ideas, and develop your team members. Identifying a goal or value that can be used as a “compass” can contribute to avoiding actions and behaviours you will regret later.

Don’t Let Your Software Requirements Die

Written by Chris Rickard on April 11, 2024. Posted in Articles.

In the realm of software development, the clarity and accuracy of software requirements are pivotal for project success. Traditionally viewed as static documents to be archived post-project, this perspective neglects their ongoing potential.

Living software requirements is a paradigm where these documents evolve continually with the software, serving as an enduring source of truth. This approach not only maintains relevance but also actively shapes the software’s lifecycle, promoting adaptability and precision in development processes.

They ensure that as software grows and changes, the documentation is not left behind, thus avoiding the pitfalls of outdated or irrelevant information – because often zero documentation is worse than out of date documentation!

How requirements slowly die.

Picture this: a new software project kicks off with energy and optimism. The business analyst dives deep, engaging with stakeholders to gather an amazing set of requirements. They craft an impressive functional specification that serves as the project’s North Star, and as the project kicks off, hundreds of tasks get populated into a project management tool like Jira, mapping out the journey ahead.

The software delivery team starts strong.

As expected, questions and clarifications emerge, evolving the requirements a little. Some tasks need tweaks; others have missing components, and there are even some sew requirements that surface. This is fine (we are agile after all!) – and these changes and additions are all added into the project management tool, as that’s now the source of truth keeping the project on track.

As the tasks are ticked off, a sense of accomplishment fills the air. Finally, the project crosses the finish line, the board clears, and it’s a wrap. Success!

Or is it? Software, particularly the large, mission-critical kind, is never truly ‘done.’

The project may have ended, but the software lives on, continuous adaptation and enhancement are normal these days. But scoping new tasks becomes a little harder, as the detailed system knowledge from that original functional specification, has now changed. The source of truth is now fragmented across completed Jira tasks and buried in comment threads.

In this scenario, the requirements didn’t just become obsolete; they died a slow death, leaving the team navigating a labyrinth of past decisions and discussions to grasp the full scope of their own software.

How to keep my requirements alive?

Keeping software requirements alive is pivotal for the long-term health and adaptability of your system. Rather than relegating these crucial insights to a static document, consider embedding them within a collaborative platform accessible to the entire organization. This living, breathing approach ensures that requirements can evolve alongside your software, reflecting real-time changes and decisions. Here’s how you can make it happen:

1. Centralize requirements and allow collaboration: Choose a platform where stakeholders across the business can access, review, and iterate on the requirements. This system should be the go-to source for everything related to what your software does and why, and platforms such as Userdoc are specifically tailored to this task.

2. Project management integration: While the main body of requirements should live outside, ensure there’s a seamless flow of information into your project management tools like Jira. This helps in translating the high-level requirements into actionable tasks and ensures day-to-day activities align with the broader goals.

3. Continuous updates and iterations: Encourage a culture where updating the requirements is part of the process, not an afterthought. This keeps the requirements current and relevant throughout the software lifecycle.

4. Embrace AI – AI can be an amazing tool for helping determine what changes could affect other parts of your system, and understanding that when writing requirements for New Feature X, you will also need to update Existing Feature Y’s requirements.

5. Requirements versioning: Just like with code, software requirements need versions and branches. Ensure you clearly denote what features are live, what features are in development, and what features are still being scoped.

6. Living reference for all teams: From development to QA, from business analysts to project managers, ensure that everyone references and contributes to the same set of requirements. This alignment prevents information silos and fosters a unified understanding of the system.

7. Long-term business asset: Beyond project completion, maintain these requirements as a living record of what’s in place. This becomes invaluable for training, onboarding, and new developers understanding the system’s capabilities and limitations. It also ensures the source code isn’t the only source of truth for the system’s functionality.

Transforming your software requirements into living documentation is a strategic move that pays dividends throughout the lifecycle of your software.

And the thing is, it’s not actually doing any extra work – it’s just simply unifying the place where that work is done, and fostering a culture of continuous collaboration and documentation.

Embrace the concept of living software requirements and watch your software, and team, move faster with more confidence.

Unveiling the Unsaid: The Power of Subtle Stakeholder Cues

Written by Adrian Reed on April 10, 2024. Posted in Articles.

When eliciting information from stakeholders, often what isn’t said can be as significant as what is said. Of course, the information that a stakeholder explicitly mentions is of crucial importance, but often there are subtle and nuanced details that aren’t obvious unless you look for them. Perhaps a stakeholder subtly pauses and looks uncomfortable and avoids answering a specific part of a question. Or perhaps they use a qualifying word like “usually” or “sometimes”. Either way, it is crucial to probe further and find out more.

Hearing What You Expect To Hear

Looking out for these clues is important, but is easier said than done, particularly when time is tight. When there are a number of stakeholders to speak to, it is easy to get drawn into a pattern of hearing what you expect to hear. We’ve probably all experienced this: after three people from different departments outline a process consistently, speaking to the fourth and fifth person seems like ticking a box. After all, they are going to just confirm what the first three people have described, surely?

That might be the case, but equally they might have additional insights that the original three did not. There is presumably a reason that they have been selected to participate in the elicitation activities, perhaps because they have a different perspective on things. Yet, it would be easy to let those discussions be swayed by the conversations that have happened before. To almost go on ‘autopilot’ and lead the stakeholder in a particular direction. It is worth being especially aware of those subtle cues and nuances in situations like this.

An Example

Imagine interviewing a stakeholder in a finance team about the invoice payment process. You’ve spoken to other stakeholders previously and you’re pretty sure you know the process:

“So, you get an invoice in, and as long as there’s a purchase order number on there, and as long as it’s approved, it gets scheduled for payment, is that right?”

“So, yes, mainly…. Yeah, mostly that’s it.”

It’d be easy to move on from this. It would be easy to assume that they are confirming some of the key decision rules (if an invoice has a purchase order number and has been approved, it gets scheduled). But the stakeholder has added qualifying words: mainly and mostly. These are easy to miss, but definitely require probing.

Probing might go like this:

“I noticed you said that this is mainly how the process works, are there other circumstances?”

“Yes, only very occasionally though. Sometimes, we get ‘proforma’ invoices that have to be paid immediately. We have a different process for those. Also, there are some cases where we pay up front by credit card. For example, booking training and conference places. That has a slightly different process too.”

Suddenly, a whole new set of facts becomes available. If this were a real situation, this would lead to further probing (e.g. “Are there any other times when the process operates differently?”, “Is there just one corporate credit card, and if so who is responsible for it” etc, etc).

Make Sure They Feel Heard

Of course, probing this way is important to ensure that nothing crucial is missed. However, genuinely listening is important for another reason too: to ensure that people actually feel heard.

If you’ve ever had the experience of speaking to someone who appears to be preoccupied, and is perhaps presuming what your responses are, you’ll know that this rarely feels great. As analysts, it’s important that we empathize with and genuinely hear what people are saying.

Listening in this way will help uncover important information. It is a crucial and often taken for granted skill, but one that we can probably all hone and improve upon!