Tag: Success

“BREAKING THE FRAME”: A Paradigm Shift in Problem-Solving

Written by Neethu Nair on March 21, 2024. Posted in Articles.

In the realm of business analysis, problem-solving isn’t just a task; it’s a craft. We’re constantly challenged to find solutions to complex issues that impact our organizations’ success. Let us explore a transformative concept in problem-solving: “Breaking the Frame”!

At its core, breaking the frame is about challenging the status quo and approaching problems from a fresh perspective. It’s about stepping outside the boundaries of conventional thinking to uncover hidden opportunities and drive meaningful change.

Consider the “Slow Elevator Story.” Tenants in a building complained about the sluggishness of the elevator, prompting the manager to seek solutions. Traditional problem-solving methods would have led to expensive elevator upgrades. However, by thinking outside the box, a simple yet effective solution was found: installing a mirror in the elevator. This small change altered the perception of time, reducing complaints without the need for costly renovations.

So, how can we apply this concept of breaking the frame to our own problem-solving endeavours?

Reframing the problem: Instead of accepting the problem as presented, dig deeper to uncover its root causes and underlying assumptions.
Diverse Perspectives: Embrace diverse viewpoints and collaborate with colleagues from various backgrounds to gain fresh insights into the problem.
Creative Solutions: Be open to unconventional ideas and approaches that may lead to innovative solutions beyond traditional boundaries.
Holistic Analysis: Consider the broader context surrounding the problem, including external factors, stakeholders’ perspectives, and long-term implications.
Iterative Approach: Adopt an iterative problem-solving approach, where solutions are continuously refined based on feedback and new insights.
Experimentation: Embrace a culture of experimentation, where hypotheses are tested, and failures are viewed as learning opportunities.
Data-Driven Decision Making: Utilize data and analytics to inform problem-solving, ensuring decisions are grounded in evidence and insights.
User-Centric Design: Place the end-user at the centre of problem-solving efforts, empathizing with their needs and preferences.

The elevator may or may not be slow, but the point here is “Is there a better or smarter way to solve the problem?” . By reframing our approach to problem-solving, we can uncover hidden opportunities and propel our organizations forward.

In the realm of business analysis, breaking the frame isn’t just about solving problems; it’s about driving innovation and creating value. By reframing our approach to problem-solving, we can uncover hidden opportunities and propel our organizations forward.

“If I had a hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 mins thinking about solutions” – Albert Einstein

Therefore, let’s never simply acknowledge the problem as it’s presented. Instead, let’s break free from conventional thinking, explore beyond the established boundaries, and rephrase the given problem to uncover its underlying root causes. By doing so, we can avoid solving the wrong problems and focus on addressing the correct ones.

The key to effective problem-solving lies in embracing creativity, diversity, and a willingness to challenge the norm. Let’s embark on this journey of breaking the frame and revolutionize our approach to problem-solving in business analysis.

Ego Check: The Secret Sauce of Successful Business Analysis

Written by Steve Jones on March 14, 2024. Posted in Articles.

You’ve spent days or even weeks working through your discovery and analysis details to craft wire frames for a new application or capability. You know what your stakeholders might ask for in terms of alternatives, so you create those versions as well. The day arrives when you’re finally ready to share with business and IT, the work you’ve labored over.

The big meeting happens and your stakeholder destroys everything you’d worked so diligently over, ripping your heart out.

Sound familiar? Some people take this as a crushing defeat and question their choice of profession.

Don’t let this be you!

You need to have a thick skin in this game. As a business analyst, your role resides at the crossroads of business operations and IT solutions. Navigating the complexities and personalities of both requires not only some technical knowledge and business acumen but also a crucial personality trait — the ability to leave your ego at the door. While this notion may seem daunting at first, it stands as one of the most invaluable skills a business analyst can possess.

Bringing your ego along in conversations tends to add chaos, disrupting free-flowing communication in an environment that might already have some chaos. Setting aside your ego entails acknowledging you don’t have all the answers; that meticulously crafted strategies may necessitate revisions; and that your perspective, no matter how comprehensive, may not encapsulate the entirety of a problem or its solution.

Within the dynamics of a business environment, ego can often act as a hindrance, impeding effective communication. A business analyst who can restrain their ego is more amenable to guidance for research and receptive to feedback, fostering continuous learning and growth.

While criticism is frequently viewed unfavorably, it carries substantial value within a business context, serving as an indispensable tool for development when harnessed constructively. As BAs, our mission revolves around streamlining processes, enhancing capability & value, and facilitating change — tasks that demand perpetual scrutiny and re-evaluation. Feedback, including criticism, serves as a critical lense through which we refine our insights and strategies.

You need to be strong enough to withstand the critique to investigate what the underlying cause or comments are about. When the feedback seems overly harsh and does not feel like it is constructive, exercise what you have available to you – use your tools to continue the conversation. Start by expressing appreciation for the input. Depending on the harshness of the initial comments, this can be disarming, so utilize the connection to ask questions for feedback that could be actionable areas for your improvement.

In addition to seeking constructive feedback, you can also practice the agile principle of Simplicity. If you don’t quite understand what “the art of maximizing the amount of work not done” really means for a BA… it’s this; don’t spend so much time trying to produce a pristine wireframe or perfectly crafted requirement. Do enough to identify value during conversations.

While on a project or during a product increment, the initial requirements documentation is really intended to be just enough to draw out the valuable conversation to confirm understanding while narrowing in on the solution and it’s constraints to facilitate realization of the business value.

Internalizing feedback can obstruct the broader perspective and overall objective of the task at hand. Conversely, leveraging feedback as a means of self-improvement can significantly elevate your standing within the team, while enhancing the quality of output and fostering stronger work relationships.

Keeping your ego in check does not mean a dismissal of your ideas, opinions, or self-assurance entirely. Rather, it involves striking a balance — knowing when to advocate persistently for your ideas and when to step back, listen, and glean insights from others. For seasoned analysts, this should be second nature but it’s worth a reminder from time to time.

In conclusion, the absence of ego can quell the chaos, amplify your capacity to discover and comprehend the real issues, and embrace diverse perspectives to construct robust and effective solutions. Thus, resisting the urge to take criticism personally and ensuring that our egos do not overshadow the primary goal of problem-solving constitutes an trait every successful business analyst must master.

Do You Consider “Opportunity Cost” In Your Analysis?

Written by Adrian Reed on March 16, 2023. Posted in Articles.

I’m a fan of live music, and I particularly enjoy music festivals. If you’ve never been to a music festival, you’re missing out. They usually involve multiple days of listening to music, dancing and having fun. There’s often multiple stages so one challenge is deciding which bands to listen to.

I was reminded of this fact last summer when I bumped into a friend of mine (who is also a BA) at a music festival. It turned out that we’d both created (and printed) spreadsheets showing who was playing when at what time. My spreadsheet even used color coding with green being bands we planned to see, and yellow being ‘backups’ (in case the first choice was too full, or there was some other reason we couldn’t get there). Well, everyone loves a spreadsheet, don’t they?

Comparison and Opportunity Cost

Spreadsheets aside, this illustrates a point that is important in projects and product development initiatives too. Typically every action or decision has an opportunity cost associated with it. Taking one course of action means that it isn’t possible to pursue others (as time and budget is focused on the course of action that’s been chosen).

At a music festival, the opportunity cost is fairly easy to calculate. If I see Band A on the main stage at 8pm, I can’t see Band B on another stage at the same time. I also can’t go to the bar (probably for the best), nor can I grab an overpriced hotdog. The act of deciding on an action means that other options are no longer open to me.

The same is true when it comes to deciding which projects to progress, which features to focus on, or which requirements to prioritize. When writing an options paper, it’s usual to consider the impact of ‘doing nothing’, but in some cases it may be worth extending the thinking even further and considering what else could be done with the time and money.

When prioritizing requirements, there are always trade-offs. It’s desirable to deliver the features first that will enable the most benefit to be realized. This is certainly true, and this is something that I’m sure we all aspire to… but in reality aren’t things often a bit more complicated than that? There’s often resource contention (multiple development and testing teams, often with limited resources), organizational level challenges (code freezes, budget changes) and a whole load of other opportunities and threats outside of the immediate orbit of the project.

Sometimes It Makes Sense To Do The Second Best Thing

There might be cases when it actually makes sense to do the second most beneficial thing. Imagine there’s a high priority set of requirements. Everyone agrees those will yield the most benefit. However, the technical experts that need to work on them are also needed to work on some essential maintenance. Although systems maintenance and the art of ‘keeping the lights on’ is never as glamorous as delivering new features, it’s still super important.

Within the project, the logical decision is to go for the highest priority requirements. But, there’s an opportunity cost for the organization. If that action is taken, the maintenance is delayed. That might be a very bad idea, depending on the nature of the maintenance.

The key point here is that progressing the second best thing for the project might actually be the best thing for the organization overall.

Know Which Decision Options Are “Perishable”

Some options available to us “perish” if they aren’t taken. If you’re at an airport and delay deciding whether to get on the plane for too long, your option to board that plane will eventually disappear (as it’ll have taken off without you). The same is true at a music festival, if Band A clashes with Band B, then you have a straight choice to make. Choosing Band A means you don’t see Band B at that festival.

These are different from prioritization decisions where you can do both things sequentially. Delaying requirement A so the team can do some urgent maintenance probably doesn’t mean that requirement A will never be delivered… it’ll just be delayed. There will be an impact on the timing of benefits realization, but it’s not a binary “yes or no” decision. It’s important these types of prioritization decisions are separated from those where there really is one chance, and one chance only.

BAs as Facilitators of Decision Making

All of this leads to an interesting conclusion: An important and often overlooked element of the BA role is to facilitate decision making. Whether that’s over prioritization of projects, feature requests, requirements or something else, we are on hand to analyze the different perspectives and ensure an informed decision is made.

Ensuring that we do this consciously, taking into account multiple factors (while keeping ‘opportunity cost’ in mind) is crucial. It’s one of the many areas where BAs add value!

Best of BATimes: A Checklist For Business Analysis Planning

Written by Edmund Metera on September 8, 2022. Posted in Articles.

Use the Universal Business Analysis Planning Checklist as You Plan Your Business Analysis Approach.

Every project is a unique, temporary endeavor.

The business process management, regulatory compliance and digital transformation projects that business analysts may play a role in all come with different goals, scopes, teams, timelines, budgets dependencies and risks. Though many projects follow similar methodologies they are all tailored for project scope constraints and to take advantage of available resources, opportunities and lessons learned from prior work.

Each business analyst also comes with a unique set of skills and experiences. Almost all business analysts have great communications skills and at least some experience-based business domain knowledge. That’s why they became business analysts in the first place. Every business analyst has uniquely acquired knowledge of business analysis techniques and business domains through personal study, practice and experience. Many have also been trained in elicitation, requirements management, modeling, measurement, analysis and documentation techniques. An ever-growing number have received professional certifications, such as the IIBA Certified Business Analysis Professional (CBAP) or the PMI Professional in Business Analysis (PMI-PBA).

What is Business Analysis Planning?

The most skilled business analysts are not only competent in many business analysis techniques but also consciously tailor their business analysis approach for each project that they engage in. They have learned to consider key project dynamics along with their own competencies and to tailor their planned business activities and deliverables to suit each project’s unique dynamics. Regardless of your own level of business analysis experience, maturity, and whether you are formally trained, certified or not, you can still consciously assess each project’s dynamics and tailor your forthcoming business analysis work to get the most productivity and value out of your business analysis efforts in each project.

The most significant project dynamics include:

The methodology, or sequence of stages or major milestones, and the business analysis products or outcomes that are expected by the end of each stage/milestone (and before starting the next).
The budget and schedule, not only to meet them, but to take advantage of contingency or schedule slack opportunities, to increase the value, quality or to learn.
The key project stakeholders and relationships that are new and changed and forming, to take a proactive role in fostering and building relationships with and among that team.
The types and combinations of elicitation techniques that will be best suited for producing or validating business analysis deliverables.
The business domain knowledge and experiences of the diverse key project stakeholders, including your own unique set of business analysis competencies.

The Universal Business Analysis Planning Checklist

You can be more effective in planning your business analysis approach if you follow a consistent, clear agenda that considers the common project dynamics.

The Universal Business Analysis Approach Planning Checklist covers the most common project dynamics. You can use this as an agenda to elicit and discover a comprehensive view of a project’s key dynamics, its opportunities and use what you discover to adapt/tailor your business analysis approach.

As an exercise, think of a project that you have recently worked on, you are currently working on, or will soon be working on. Answer questions in the following checklist for yourself.

Project Life Cycle

What are the planned stages of this project?
What stage are we currently in?
What is the business analysis deliverable (or set of deliverables) that I am responsible for producing in this stage?
What is the intended use of my business analysis deliverable(s) and who will use it?

Schedule And Effort Budget

How much effort can I spend and by what target date am I expected to produce my business analysis deliverable(s)?
Is that about what I also estimate it will take?
Is either my effort or date estimate higher than the effort budget or target date? If so, how might I adapt my effort, scope, activities or configuration of my deliverable(s)?

Project Stakeholders And Relationships

- What are the key roles is on the project team and who is in them?
  - Does this project have an executive sponsor, project owner or product owner, project manager, specialists and business subject matter experts?
  - What are the names and titles the persons in these project roles?
- Are significantly new relationships being are created in this project?
  - Who’s new to each other on this team?
  - Are there local and who’s remote team members?
- What are peoples’ responsibilities?
  - Who is responsible for producing, accepting or needs to be consulted or informed of each of the project’s key deliverables, particularly the business analysis deliverable(s)?

Elicitation Techniques

Which elicitation techniques are available to me use?
- Documentation Reviews – What documentation or prior work products are available to review?
- Interviews and Workshops – Who can I interview or include in a workshop, and what questions would I need to ask?
- Observations – Where and what kinds of observations may be needed and how could I arrange for them?
- System reviews – What system(s) are available to review and for what information?
- Surveys – Who could I engage in a survey and using what types of questions?
What are my own business analysis competencies?
- Considering this project’s stakeholders and relationships, the elicitation techniques available to me, and my own core competencies, which elicitation techniques are best suited gather and validate my business analysis information?

Organizational Assets

What specialized tools for elicitation, documentation and modeling are available to me?
- Collaboration tools, facilities, survey tools?
- Diagramming or modeling software?
What prior business analysis work (e.g., documents, models) that I can draw from?
Does my organization offer training in the subject business domain?

Competencies And Knowledge

Who on the project team has what expert business domain knowledge?
What is my own business domain knowledge?
What are my strongest core business analysis competencies?
Where can you take advantage the team’s diversity of knowledge and competencies?
Who are the best stakeholders in this project to engage in elicitation of content or validation of business analysis deliverables and what is or are the best elicitation techniques to use?

On reflection, are you able to answer these questions for yourself? When you go into your project workplace, who will you include in this conversation?

Conclusion:

Business analysis planning is a recognized business analysis activity. The IIBA Body of Knowledge (BoK) includes the Plan Business Analysis Approach activity within its Business Analysis Planning and Management process. The BoK also lays out the scope of what should be covered by a Business Analysis Approach as “The set of processes, templates, and activities that will be used to perform business analysis in a specific context.”

The time and formality that you apply to business analysis planning is up to you. At the financial institution where I work as a project and program manager, our business analysts typically tailor and document a business analysis plan for each new project to which they are assigned.

I think of business analysis planning as a form of insurance. Spend a little time upfront to assure that the bulk of the rest of your business analysis efforts will be as well spent and effective as possible. Expect the benefits of tailoring a business analysis plan for every project to be that:

It will help you to align your own core business analysis competencies to each project, and
You and the project will gain the most value from your business analysis efforts.

That’s a value-adding proposition.

You are welcome to contribute comments about project dynamics that impact business analysis plans or about the checklist presented through the Contact Us page at www.ProcessModelingAdvisor.com.

Constructive Conflict Is Better Than False Agreement

Written by Adrian Reed on July 21, 2022. Posted in Articles.

Over a decade ago, I was in a workshop with a range of different stakeholders.

Everything seemed to be going well, and people seemed to be agreeing and we were even running ahead of the meeting schedule. Around halfway through the meeting a particular issue was being discussed, a conclusion was going to be drawn and a stakeholder interjected strongly and firmly with two powerful words. They simply said:

“I disagree”

I remember being taken aback by the bluntness. I live in the UK and our communication style is somewhat indirect most of the time. It’s far more normal to say “Hmmm, interesting idea, or what about…?” which is code for “That’s a crazy idea”. Or often the temptation might be to revert to the ultimate British stereotype and apologize “Sorry to be a pain here, but I’m not sure I entirely agree”. I’m sure British culture is not the only one that has such indirect nuance.

The reason I remember this meeting so vividly, even more than a decade ago is that those two words initially made people visibly uncomfortable. Someone was breaking the consensus; they were “creating conflict”. Yet that wasn’t the intention, and of course they didn’t just say that, the stakeholder went on to explain the source of their disagreement, and what they proposed instead. Thirty seconds later (once the stakeholder had explained themselves) any feeling of discomfort gently dispersed. What’s more, other attendees of the meeting started to question things, interject and show disagreement. One stakeholder questioning a decision had the apparent result in creating perceived permission for others to do so. And you know what? I am convinced that the output of that meeting was better as a result.

Don’t Let Conflict Fester

Many of us have been taught to consider conflict as bad and consensus as good. I suppose that is true in an ideal case, but if you’re working on any kind of large scale change how realistic is it that every stakeholder is really going to be ‘on the same page’ and in total agreement? If a government implements a new type of tax and requires businesses to submit more information, there’s unlikely to be a standing ovation from business owners. Yet that doesn’t mean that their input isn’t valuable—I would go as far as saying it’s essential!

Our fixation with consensus can lead to a situation where we achieve illusory agreement, a veneer of satisfaction. Dissenting voices get marginalized, as they’ll never agree (so why spend too much time asking them?). We carefully facilitate meetings so that there aren’t big disruptive arguments, as we’re desperate to hit all of the aggressive (sorry ‘ambitious’) project deadlines. Yet this dangerous glossy veneer is very quickly broken when people start to interact with the product or service that we deliver. All we’ve done is defer the conflict to an even less convenient time, often a time when there’s so much political capital riding on the ‘solution’ that’s been designed that there’s no appetite to change it.

Cultivating Constructive Disagreement

As business analysts, we can help avoid these situations. We have the opportunity to create space for constructive and respectful conflict, and we should certainly avoid us or others sidelining people just because they have contradictory views. In our analysis activities we should encourage constructive and respectful disagreement.

Taking an example, when setting up a workshop we have the perfect opportunity for creating the opportunity for a robust and respectful discussion. We can lay down an appropriate set of ground rules that allow for differences of opinions to surface. I’ve found myself opening workshops saying things such as:

“This is a controversial topic, and there are bound to be some differences of opinion. That’s to be expected. With that in mind please do speak up at any time and add your view, but please do be prepared to elaborate on it. Keep in mind I’ll be facilitating fiercely but fairly—and there might be times when I need to ‘park’ your item for later discussion. It absolutely won’t be lost, we will come back to it, but please don’t be offended if I need to do that.”

When we facilitate, we can actively prompt, asking questions such as:

“We seem to have complete agreement here; are there any contradictory thoughts. What have we missed?”

Ensuring that stakeholders have the ‘air time’, and ensuring that the most bombastic attendees don’t steal the limelight is crucial. Using a range of tools and techniques in the workshop to consider not only what we want but also what could go wrong can be useful too. Even just asking a question such as “That seemed too simple, might we have missed something?” can help.

Most of all, cultural nuances aside, we shouldn’t be afraid of the concise clarity of an expression such as “I disagree”. When someone says it they provide us with a gift, an opportunity to better understand them.