Tag: Assessment

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.

What Apple’s Vision Pro Tells Us about User Stories

Written by Lucas Marshall on March 6, 2024. Posted in Articles.

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?

Written by Adrian Reed on October 26, 2023. Posted in Articles.

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

Written by Adrian Reed on June 23, 2022. Posted in Articles.

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:

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.

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.

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”

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!

10 Characteristics of an Awesome Business Analyst

Written by Brad Egeland on March 1, 2016. Posted in Articles. 2 Comments on 10 Characteristics of an Awesome Business Analyst

Does your organization handle large, complex technical projects? Do you have diversely skilled project teams assigned to those projects? How about overloaded project managers? Are they juggling several projects at once?

This sounds like every organization I’ve managed projects in and every company that I’ve consulted for along the way.

If this is your organization, too, then you likely need the best of the best in terms of a business analyst on each project being led and executed on for the project customers your organization is serving.

If you do need the “best of the best”, then what skills or characteristics are you looking for? What defines the best for your organization’s project needs?

While BAs are not project managers, the most successful BAs manage the entire business analysis effort. This means that the BA is proactive and dependency-aware. It also means they manage themselves well, the stay on track with respect to commitments and deadlines, and can handle task delegation, decision-making, and issue management as needed on the project.

I’ve thought about the overall skill set and characteristics needed to conduct this role efficiently and productively. Coupled it with my experience leading projects, working in combined project manager and business analyst roles I’ve come up with my list of ten characteristics of an awesome business analyst.

{module ad 300×100 Large mobile}

As you are reading through these, please be thinking of your own personal experiences and comment with your additions to this list.

Great customer interface. The great business analyst is a critical liaison between the project manager and the technical team. This person is often the driving force behind the accurate, complete, and detailed documentation of the final project requirements. Why? Because the organizational to tech cross-over ability and skills that many project managers will lack must be handled in this role. And they help the tech lead interpret those functional design ideas into technical design specifications for the design and development work on complex technical solutions.

Subject matter expert. The skilled business analyst is vital in their project team role as a subject matter expert. This helps them to work with the client to document accurate business processes that are then used to create detailed, complete, and accurate project requirements.

The business analyst’s technical knowledge coupled with his understanding of the design process and the likely end solution makes him an invaluable resource for the project manager the project team and the project client.

Good technical cross-over. The very valuable business analyst has a diverse amount of technical knowledge. Not necessarily tech lead or developer knowledge, though that is a plus, but rather a very good technical acumen that gels with the project management-type organizational skills and knowledge they also likely possess.

Can project manage it when needed. The indispensable business analyst can and often acts in the role of project manager, both when the project manager may be tied up on another project and also when interfacing with the team and client and a decision needs to be made if the project manager isn’t currently available.

Critical attention to detail. Detail-oriented focus is needed by the business analyst on the project for a variety of reasons: to assist the project manager and fill in there as needed, to work closely with the customer sponsor and team and the project team to define and document requirements, and to help track and resolve issues throughout the engagement.

Skilled communicator. I’ve often said that communication is Job One for the project manager. However, communication skills are possibly the most important characteristic of the awesome business analyst if for no other reason than the vast responsibilities this position has on the project and with the team and customer.

Miscommunication can lead to so many problems on the project. The awesome business analyst ends up interfacing with all stakeholders, making accurate and thorough communication necessary.

Facilitation skills. The business analyst is going to be required to facilitate many meetings and sessions during the project such as periodically leading the team meetings and formal project status meetings for the project manager and then requirements meetings with the customer as well as design sessions with the technical project team.

Experienced critical thinker. Business analysts are responsible for evaluating multiple options before helping a team settle on a solution. While discovering the problem to be solved, business analysts must listen to stakeholder needs but also critically consider those needs and ask probing questions until the real need is surfaced and understood. This is what makes critical thinking and evaluation skills important for the business analyst on the project.

Skilled with PM and organizational tools. The business analyst needs to have a good command of the use of various project management related tools such as project scheduling software, basic tools like Word, Excel and PowerPoint, and others that might be needed such as task management software, bug tracking software, risk management software, file management software, and even modeling tools like Visio, etc.

Conflict resolution. From time to time conflicts can arise. I’m not talking about fisticuffs…at least I hope not. But disagreements among technical team members or with members of the customer’s staff can arise. The skilled BA will recognize this quickly and work with both sides to come to a mutual agreement. Patience is also a virtue because any conflict resolution requires patience and understanding. And good listening skills.

Summary / call for input

The business analyst isn’t necessarily the leader on the project, but his role may be the most diverse and sometimes the most critically necessary for project success. The project manager will serve as the overall communicator and decision maker on the project, but the business analyst will likely have an even closer customer facing role than the project manager, meaning this position may be the most valuable in helping ensure customer satisfaction and completeness and acceptance of project work performed by the project team.

How about our readers? If you’re a business analyst, what do you think about this list? What would you add to or remove from this list? What are your top 3 or top 5 characteristics for a valuable business analyst? Some organizations – often smaller organizations – may only hire a project manager or business analyst to handle both roles. Have you worked with such an organization and did you find it to be successful?