Skip to main content

Tag: Assessment

Business Analysis: How and Why Do I Need To Evolve?

Without a doubt, artificial intelligence (AI) is here to stay and is not going anywhere. Still, it would and has even started disrupting the status quo of many industries and organizations. Well, this is an undisputable, crucial innovation. Still, I would gladly refute Elon Musk’s’ claim that “We will have for the first time something smarter than the smartest human. It’s hard to say exactly what that moment is, but there will come a point where no job is needed” (Marr,2023).

The human factor must be considered in every career path or industry; however, professionals in every space and sphere must evolve with the dynamic and changing environment.

Why do we need to evolve?

Regarding my specialization as a Business Analyst, how and why do I need to evolve?

Recently, there has been a surge in the search for business analysts. This is not because this is a new field; instead, it has existed since the Middle of the Old Stone Age, when the ancestors were able to effectively adapt to the changing natural environment, identify their needs, problems, and opportunities, and develop solutions to make their abode livable and habitable.


What is Business Analysis?

According to the BABOK Guide V3, Business analysis enables change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change and design and describe solutions that deliver value.

The business analysis field has undergone several nomenclature changes and could be referred to by different names in different industries. Some famous names include Business systems analysis, business process analysis, functional analysis, product ownership, systems architecture, project management, usability analysis, user experience consulting, operations assessment, and technical writing.


Business Analysis Requirements

The BABOK Guide v3 views requirements as a usable representation of a need and a design as the usable requirement of a solution. Still, both concepts can be used interchangeably and primarily depend on the context of being used or adopted. Requirements need to be identified, collected, modeled, analyzed, validated, verified, traced, prioritized, managed, and maintained in the lifecycle of a project (Pre and post-project stages). Still, they are all related to a business problem that requires a solution. It could be in the form of an organizational objective that must be met, a business process that needs to be optimized, and an existing solution that needs to be improved or even retired. The BABOK guide v3 defines a Context as the circumstances that influence or are influenced and provide an understanding of a required change. This explains that requirements are broad and depend on the context, such as industry, regulation, project, weather, attitudes, behaviors, etc.




Unpacking BA requirements for Artificial Intelligence

Business analysts should not view themselves as AI experts but understand that they exist to drive change while still understanding the capabilities that AI provides and its complexities. Business analysts must see themselves as a bridge between business needs and AI capabilities.

Understanding the complexities of AI algorithms may and may not be a hard nut to crack; however, with a fundamental understanding of Natural language processing/ machine learning and knowing that most AI tools have been embedded with the critical technology to understand human language, as well as the ability to sieve through large data sets and establish a pattern or relationships, could serve as helpful information. Business Analysis could also establish broader knowledge of AI capabilities.

Also, the core of business analysis is need identification and solution generation. Both are valuable, but the most critical is correctly and efficiently identifying existing needs or problems, thus providing room for developing requirements and generating solutions.

This brings us to the question: can AI help in need identification or problem assessment? Realistically, with established data and available documentation, AI could help identify a need, but Hey, that need would be missing users’ humanity. Whatever solution is generated should provide or enhance satisfaction. However, can AI understand the complexity of the human emotion? With AI, we could develop the goals, desired outcomes, and key performance indicators (KPIs) and define roles and responsibilities, but how can usability be assessed?

With AI in business analysis requirements comes data quality, security, and privacy requirements. Every requirement generated for BA activities must answer these 3 data prongs. How reliable is the requirement gathered? If a requirement is trustworthy, it could speak to its quality. Was the requirement confirmed, verified by necessary stakeholders, and validated to align with identified needs?

To achieve these three tasks, the requirements must be specified and modeled to fit the organization’s environment with due consideration of the stakeholders involved. The modeling can be in the form of matrices or even diagrams, for which AI could be beneficial. Still, the prompts must be correct, which reflects the data quality and reliability. Using AI to generate, specify, or even model requirements (inexhaustive) would lead to data security and privacy prongs.

Privacy and security are critical issues in the professional world, not just business analysis. Before every BA task, how AI should be adopted and what data should be provided as AI prompts need to be addressed. There is a need to protect user privacy and define adequate security measures, as IT systems are susceptible to attacks. Privately owned AI tools can still be attacked; strict security and privacy rules must be strictly followed.

This is also very important as some requirements can serve as Unique selling points for a specific business or even a trade secret. In this situation, the use of AI might be optional.



Knowing that the Business analysis role will continue to evolve as a context evolves or dictates or even as a business dictates while putting Artificial intelligence as an addition in a context, it is recommended that the requirements generated in previous contexts be adequately managed and maintained for reuse. When done correctly, this would enhance knowledge sharing as AI could help create a central repository for past project requirements, thus making it easier for business analysts to learn from past experiences and build on existing knowledge, which could lead to overall project success.


Beyond Frameworks: Agile Insights from a BA’s Odyssey

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.

What Apple’s Vision Pro Tells Us about User Stories

The Verge released a story recently reporting how early buyers of Apple’s Vision Pro “spatial reality” headset were already returning their devices to take advantage of Apple’s 14-day return policy window.

But why?

In this article, I’ll recap the issues sprouting up around this nonetheless revolutionary product in order to make a couple of arguments: 1) How Apple’s approach to hardware development may (to a fault) prioritize perceived quality over functional requirements, and 2) What user stories for a hardware/software product may necessitate to make future generations more viable for widespread adoption.


Problems Abound in VR, but Did Apple Put Form before Function?

The key issues cited for returns of the Apple Vision Pro are usability issues coupled with a hefty price tag (i.e., $3,500 MSRP).

That’s not to say buyers aren’t blown away by the revolutionary UI and what the device is capable of. Rather, users’ concerns are that—relative to the high price tag and usability issues—they simply can’t justify the expense for a device that presents these usability concerns. The price isn’t worth the experience, in other words.

Consider some of the tweets on X (formerly Twitter) from users describing their experiences with the device and ultimately their reasons for returning their headsets to Apple:

“Can’t wait to return the Vision Pro, probably the most mind blowing piece of tech I’ve ever tried. Can’t deal with these headaches after 10 minutes of use though,” tweets one user.

“Two hours after unboxing my Apple Vision Pro and using it, I decided to box it back up again and return it. It’s quite cool, but there’s nothing in it for me that I’ll use frequently enough to warrant my keeping it,” tweets another.

Virtual reality headsets are a complicated product category and represent an exceedingly difficult problem to solve considering the technical and physical challenges. I’ve reported on how, for example, ergonomics are a known issue.

Consider the problems a VR headset must address:

  • Weight – Obviously, a perfect solution doesn’t yet exist, but as some reviewers have reported, Meta’s redistribution of weight and use of pancake lenses in place of Fresnel lenses in their Meta Quest Pro represent an attempt to resolve UX problems their earlier Quest 2 presented. Considering that VR headsets aren’t a new category, reviewers may have liked to see a better first showing from Apple regarding the ergonomics issues related to weight distribution.
  • Price – With the $3,500 price tag (compared to $999.99 for Meta’s Quest Pro), price is an issue. Certainly, higher grade materials which play important parts of Apple’s industrial design philosophy and sustainability goals contribute to the heavier form factor compared to other headsets that rely on plastics. That said, alternative materials such as recycled plastics represent another way to reduce costs (e.g., potentially by 25-50%) while simultaneously addressing the weight issue.


User Stories and Understanding Evolving Needs

If you’ve seen the 2023 film, Blackberry, about how the once-dominant smartphone predating the iPhone (and later competitive offerings from Samsung), you know that the one thing the titular product from Research in Motion (the company that invented the product category) is that getting there first doesn’t mean staying there indefinitely.

The case of Blockbuster versus Netflix tells a similar story, where a giant who’s become the dominant force in the marketplace is complacent, slow to innovate (due to their complacency), and is disrupted.

In the case of Apple, they weren’t there first in the VR category. They also weren’t the first to the smartphone category, but in the case of the smartphone, they completely redefined the category.

Have they innovated enough while addressing known user problems in the category?

Certainly, Apple has created a revolutionary product, but as Mark Zuckerberg points out, the device doesn’t provide an experience so leaps and bounds ahead of its competitors that it warrants the price and the persistent UX problems.

In short: The Apple Vision Pro isn’t to the AR/VR product category what the iPhone was to the smartphone category.





What User Stories May Have Detailed: Ergonomics at the Center of Industrial Design to Solve Known User Problems

Chief among the user problems with the Apple Vision Pro is the ergonomics problem.

Considering the Verge report of customers returning their Vision Pro headsets with complaints of discomfort relative to the weightiness of the device for extended periods, it’s safe to say Apple hasn’t cracked the ergonomics problem on their first try.

But it’s also safe to say it’s a problem no manufacturer has truly solved, but Apple’s form factor doesn’t help. Consider, for example, how weight has been a known problem in VR applications studied by scholars.

Future iterations of these devices should seek to address the known ergonomics problems users are experiencing.


Example of Ergonomics-First Industrial Design

To stray away from VR headsets for a moment to talk just to ergonomics and how to approach solving real-world ergonomics problems, let me offer an example.

Heavy-duty power tools provide one real-world application where ergonomics are of heightened concern—we’re dealing with workers’ livelihoods and safety in situations that are inherently dangerous, after all. Characteristics of ergonomic power tools typically look to address a combination of weight, shape, and grip to provide a form factor that is as-comfortable-as-possible relative to the application.

Consider some of the common causes of musculoskeletal disorders like trigger finger (e.g., overexertion and repetitive motion) from a person’s finger becoming locked in a bent position as the result of repeatedly gripping and pulling the trigger of a crimper, for example.

Equipped with this known issue, the M18™ FORCE LOGIC™ 12 Ton Utility Crimper introduced a high-capacity muscle testing system to design the tool to require less than eight pounds of trigger release, which is 75% less than other crimpers, while also delivering an improved center of gravity and a significant weight reduction to the tool. What’s more, it requires 47% less muscle effort to use.

The example from Meta’s Quest Pro of redistributing the batteries to address the balance issue in earlier iterations is one that shows promise and Apple may take notice when addressing their own device’s weight problems.


Bottom Line

We may not have cracked the ergonomics problem associated with VR applications, but Apple may look at existing heavy hitters in the category, like Meta, as they tweak their own device’s shortfalls.

Outside of consumer applications, AR and VR offer exciting prospects for productivity enhancements in industries that could stand to gain in productivity like AEC: Studies have looked at the use of VR in safety training (e.g., articles have been published in Applied Sciences, additional research has been produced by California Polytechnic State University, and conference talks have been given on the subject).

If Apple can address the ergonomics and cost issues by prioritizing user needs, their Vision Pro headset may be the construction wearable of choice companies use to onboard new employees, train apprentices, and conduct safety demonstrations in the application to provide greater educational outcomes for the next generation of construction professionals.

Have You Considered “Customer Information Needs” In Your Process?

A while ago, I was sitting in an airport where all flights were delayed due to weather. As is quite often the case in situations like this, staff at the gate initially don’t have a great deal of information available to them. In my experience, airport staff will do everything they can to keep customers updated, but sometimes they seem to know little more than the passengers (and are probably every bit as eager to know what is going on!).

What has changed in the last ten or so years is that getting information from outside sources is a lot easier. While some people were lining up to speak to the gate staff, others were accessing apps to try to piece together what was going on.  For example:


  • Using a flight tracking app, I could see planes that were previously in a ‘holding pattern’ above had now changed direction (very likely they were diverting to other airports)
  • Looking at other airports’ websites, I could see flights destined for this location due to leave hours ago had not left (presumably as the weather had been forecast). I concluded this might cause a problem, as even if the weather clears, the aircraft and staff won’t be here to conduct the onward/return flights (and even if they are, perhaps the flight crew might have exceeded the number of hours they are allowed to work without a break)
  • Looking out of the window, I could see that the weather appeared to be getting worse, not better…
  • When I accessed a hotel booking app, I could see hotels in the area starting to sell out of rooms. I started to worry that if the flight was canceled, there wouldn’t be anywhere to stay


The airport and gate staff were incredibly helpful, to the extent that they could be, but the only information they could really give is “flight delayed: next update in an hour”.  The irony was that a consumer had access to more information via free smartphone apps than the airport representative was able to share.

I made a decision to stick with it, but assumed that I probably wasn’t going anywhere that day. My prediction came true, and after a mad scramble I thankfully did get a hotel room for the night and flew late the next afternoon.




Customers Need Information

It will come as no surprise that for customers to have a good experience of a service, they need accurate information at key times. If you’ve ever flown on an airplane, you’ve probably found most airports are pretty efficient at managing routine information flow. There might be hundreds of other flights leaving on the same day, but it’s usually pretty easy to know what terminal and gate you’re leaving from. Airports are usually also pretty good at getting people to the gate on time (even if they occasionally pretend they are ‘boarding’ long before the plane is actually boarding in order to get people moving…). Issues sometimes occur when things aren’t going as planned.  This is where you have to rely on someone announcing something over a loudspeaker system, often in a noisy airport, where everyone is desperately trying to work out what is going on…


What is perhaps less obvious is that someone has designed how and when information flows to the customer. The “happy path” (where things go well) is a well-trodden and well-designed path. Perhaps some other exceptional paths are less well-designed, meaning customers are less likely to get the prompt information that they need.


Consider Information Needs

This is an area where BAs can add significant value. Quite often, the focus will be on designing a customer journey or set of business processes. That is a perfectly good approach, but at each step in a journey or process it is worth asking “what information might the customer need here” and “how can we deliver it to them?” This applies as much to the exception flows as the main “happy path”.  Often exceptions are where those “moments of truth” happen where a customer really relies on good service.

Not only this, but if a customer’s information needs are preempted, this will likely prevent queries. Imagine an announcement at an airport:

“This is an announcement for people on flight BMXXXX to Southampton.  All flights are currently grounded due to weather conditions, and all incoming flights are being diverted. We currently hope to run the flights, but right now we can’t be sure. We will be updating you every hour, and a final decision will be made at 9pm.  If we don’t fly today, you’ll get a free place on a flight tomorrow, which will be automatically allocated (you won’t need to take any action, you’ll get it via email).  If you’d prefer to voluntarily change your flight, come and see us and we’ll explain how to do this, but please do be aware a fee may apply if you opt to change before the flight is canceled”.


This isn’t perfect but it would help a passenger make a decision. It has preempted the decision they might want to make and has provided them some context.

Of course, you probably don’t work in an airport, but you almost certainly work to define and design processes that are used by people. By considering what information those people want and need during the process, in both the “happy path” and in exceptional circumstances, we can enhance the experience. And surely that is worth doing!



Analysis Efficiencies: Turning The Mirror On Ourselves

As analysts, typically we’ll spend a lot of time examining and critiquing the processes of other departments. We might be looking for ways to make an operational process slicker, quicker and ‘better’, or we might be looking to solve particular problems. There are a whole set of elicitation, problem analysis and process analysis techniques in our toolkit that help us do this. Yet how often do we turn these tools in on ourselves to examine our own practices to see if there are ways that we can improve? As practitioners of change, surely we should be looking to continually improve ourselves too?

I suspect we all intuitively do this, at least to a degree, but I wonder if it’s an area where there’s room for improvement. I’ve included some examples to whet your appetite below:


  1. Deciding How To Decide: Have you ever got to an approval gateway in a predictive (waterfall-type) project and it’s unclear who needs to make the approval? Or the approver shirks responsibility? This can manifest differently on adaptive (agile/evolutionary) initiatives, for example with wrangling over the ‘definition of done’ with different stakeholders having different (and unresolved) perspectives. These things can fester if unresolved, perhaps stakeholders concede in the short term and sign on the dotted line, but resentment builds and bubbles up, only to explode out later at the most inconvenient time.


This creates friction and drama that takes time to resolve, and when it comes to organizational change, time is money. It’s therefore beneficial to spend a little bit of time up front agreeing how these types of decisions will be made. This sounds so obvious doesn’t it? Yet, so often in the blind rush to “just get going” it isn’t discussed… and it is only as the decision emerges is the omission spotted.  Practical tools such as the RACI matrix can be extremely useful here.




  1. Planning the Requirements Architecture: When BABOK® v3 was released back in 2015, one of many significant additions was a more explicit recognition of requirements architecture. If you have ever found yourself mid-project with a whole set of useful, but disparate requirements artifacts (“These process models are great. But how on earth do they relate to those user journeys, these scenarios and those wireframes?!) you’ll know what I mean.


Taking time up front to quickly and roughly sketch out how it’s anticipated that the requirements will fit together helps avoid this. Of course, things change, as requirements emerge, new types of artifacts suddenly become relevant (“Ah, so statuses are important… I think I’ll include a state transition model…”), however having a starting point to deviate from when appropriate is better than fumbling around in the fog.

On a legislative project, you might write a quick problem statement to act as a high-level goal/outcome, and define some critical success factors/key performance indicators which will act as desired outcomes. These will all link to the organization being compliant with a piece of legislation, that’s another (external) artifact, but one which some rules can be derived from. Those rules will include internal decisions about how the legislation is interpreted; so those probably need to be captured too.  Those rules might be automated or orchestrated via processes, and there might be steps in a process which will be automated via some detailed functional solution requirements.  You can see how these different concepts relate to each other here; and of course there will be other types of artifacts too.  The point is that creating a quick sketch showing how the concepts map together before creating them will prevent artifacts from being created that don’t clearly relate to each other.


  1. Planning How To Store/Manage Requirements Artefacts: If you’re lucky, you’ll have some form of requirements (or story) management tool. If that’s the case, does everyone actually know how to use it? Is there a common agreement around how things like priorities/statuses and other metadata will be used? If not, will this create noise and friction as the initiative progresses? If so, a short discussion up-front is likely to yield significant benefit.

If you are using documents and a shared document repository (e.g. word processing tools, drawing tools, spreadsheets etc.), decide things like naming conventions and version control conventions up front. It can be very confusing when someone in the team is using a file naming convention that uses “v0.1”, “v0.2” then “v1.0” when it’s signed off, when another person is using “FILENAME v1.0 (Updated) (Second Updates) (Final) (Really Final This Time) (Updated Again).docx”


  1. Plan For The Analyst And Stakeholder Of Tomorrow: Stuff you’re creating today will be useful for the analysts and stakeholders of tomorrow. That process model you’ve created? If it’s detailed enough, I bet the training team would love to use it, and the operations team might too. It might be the catalyst to the creation of a single, unified process repository (if that doesn’t already exist in your organization).

Those performance non-functional requirements for your customer-facing website?  You know, the ones that were like pulling teeth to elicit, that required benchmarking and speaking to the technical folk? They might be a useful baseline and starting point for others producing customer-facing web applications within your organization.

As we create artifacts, we ought to be thinking not just about how they can be used today, but how they might be used tomorrow and how we can ensure they will be found.  This is a much bigger, organizational, question—however it’s one of the many areas where BAs can nudge the agenda. By creating common pools of knowledge, and by encouraging information sharing we open up channels for these types of artifacts to flow. This has the advantage that information flows in both directions and also that there will be a wider range of documents available at the start of projects too.

Of course, these are only four suggestions, there will be many more. The key is that we shouldn’t rest on our laurels; as BAs we should be looking to hone our craft and improve the efficiency and effectiveness as much as we can. This involves not just “speeding to get the job done”, but also thinking about the stakeholders of tomorrow!