Skip to main content

Tag: Best Practices

Ego Check: The Secret Sauce of Successful Business Analysis

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.

 

Advertisement

 

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.

Strings Attached: The Art of Adapting Templates in Business Analysis

I’ve recently started learning to play the ukulele. I made a decision early on that I’m not interested in learning ‘properly’, I don’t want to commit to formal lessons, I just want to try a fun new hobby. For that reason, the (very little) I’ve learned has been learned largely from YouTube.

When I say I’m not learning ‘properly’, I’m really just learning chords and tabs, I’m not reading sheet music and I’m pretty much just strumming along to the YouTube videos. That is perfectly fine for what I am aiming for, I never want to be a professional, I just want to play some simplified versions of songs I know.

 

In the dim and distant past I took piano lessons. Back then I could read sheet music (in treble and bass clef), knew about timing and some of the theory behind music. That knowledge has all gone now, and I have no idea how to play a piece of sheet music on the ukulele!

Now, you probably didn’t come here to read about ukulele playing, but there is relevance here, I promise! It’s all down to application within a context.

 

From Ukuleles To BA Templates

One of the things that I see a lot on social media is people asking for (and providing) BA templates. There’s a huge draw in using a template, it means that you don’t have to start from scratch. Things like templates and checklists can be very useful to make sure there’s consistency, and to make sure things don’t get forgotten.  (I have a travel checklist for that very reason.)

Yet a template without an understanding of the underlying theory and rationale can be dangerous. It can lead to slavish adoption (“well, I need to put this diagram in, because there’s a section for it… the template is ‘best practice’ after all”).  Just like my ukulele playing will always be restricted by my lack of music theory, someone who picks up a template without understanding why the template was created that way and what techniques can potentially accompany it will likely run into issues.

 

Advertisement

 

An Example: “BRD for the Financial Services Industry”

Let’s take an entirely fictional example and imagine that somebody produces a Business Requirements Document for the Financial Services Industry.  It is pitched as a document that will likely be used in a waterfall or incremental delivery environment, and includes a context diagram, use case diagram, scenarios, functional requirements, non-functional requirements and so on.

It’s hard to criticize any of those sections, there will be times when all of those are useful. But what if the person picking it up doesn’t know what a context diagram is? Even if they do, the whole act of eliciting information to construct a context diagram is an artform in itself.

Or, what about if you’re making a tiny change to the label on a single field? Are you really going to fill in all of those sections? You might, in some circumstances, but in all probability something more lightweight would be appropriate. In fact, a prototype alone might suffice…

Of course, this is a deliberately provocative example, but I’m sure you see the point. There really is no ‘one size fits all’ in business analysis. So much is down to context, and understanding the context is key.

 

However: Templates Can Be Useful

It is worth clarifying here that I am absolutely not arguing against templates, nor am I arguing against the appropriate sharing of templates on social media. They are extremely useful, when used appropriately by skilled practitioners. They can even act as a guide to less-experienced practitioners providing this is accompanied by a desire to learn the underlying theory and techniques.

However, templates are also most useful when they are flexible. What works in one situation won’t work in all, so cut a section, or add a section! It’s important to think about the purpose of the artifact, its consumers and how persistent it is (i.e. how long it is expected to remain current for).

Like so much in change, pragmatic and intelligent application is what matters.

Demystifying MVPs, Prototypes and Others in the BA Landscape

Let’s get some confusion out of the way. There are many different concepts and related acronyms that aren’t always used in the best way. Let’s try to clarify them.

Terms like MVP (Minimum Viable Product), MMF (Minimum Marketable Feature), MLP (Minimum Lovable Product), prototype, and proof of concept are all concepts used in product development, but they serve different purposes and have distinct characteristics. Here’s a breakdown of the differences between them:

  1. Prototype:
  • Purpose: A prototype is a preliminary version of a product used for design, testing, and demonstration purposes.
  • Focus: It primarily focuses on illustrating the product’s design, user interface, and user interactions.
  • Development Stage: Prototypes are created early in the product development process to visualize ideas and concepts before full-scale development begins.

 

      2. Proof of Concept (PoC):

  • Purpose: A proof of concept is a small-scale project or experiment designed to verify the feasibility of a particular technology, concept, or approach.
  • Focus: It concentrates on demonstrating that a specific idea or technology can work in a real-world scenario.
  • Development Stage: PoCs are often done at the very beginning of a project to assess technical feasibility.

     

     3. Minimum Viable Product (MVP):

  • Purpose: An MVP is the most basic version of a product that contains just enough delivery work to satisfy early customers and gather feedback for further development.
  • Focus: It focuses on delivering core functionality to test the product’s intended value to the customers.
  • Development Stage: MVP comes after the idea and concept but before extensive development.
  • Goal: The primary goal is to validate assumptions and learn from user feedback with minimal development effort.

 

     4. Minimum Marketable Feature (MMF):

  • Purpose: MMF is a subset of features within a product that is sufficient to make it marketable to a specific target audience.
  • Focus: It concentrates on delivering features that are essential to meet the needs of early adopters and generate sales or user adoption.
  • Development Stage: MMF typically follows the MVP phase, where you refine the product based on initial feedback and prioritize features for marketability.

 

     5. Minimum Lovable Product (MLP):

  • Purpose: MLP aims to create a version of the product that not only satisfies basic needs but also elicits an emotional response from users.
  • Focus: It goes beyond functionality to provide a delightful user experience and build strong user loyalty.
  • Development Stage: MLP often follows the MVP and MMF stages and is focused on making the product more appealing and engaging.

 

In summary, while MVP, MMF, and MLP are related to the development and release of a product, each serves a different purpose in terms of features, user experience, and market readiness. Prototypes and proof of concepts, on the other hand, are more focused on testing and validating ideas and technologies before committing to full development. In IIBA’s Guide to Product Ownership Analysis (POA®), the concepts of MVP, MMF, and Minimal Marketable Release (MMR) and Minimal Marketable Product (MMP) are introduced in terms of decision-making on what to build. The figure below is from the POA Guide and orders these four concepts. To know more about MVP with PoC and prototyping, check out a great article (with a video interview) with Fabricio Laguna (“The Brazilian BA”) and Ryland Leyton here.

Fig. 2: MVP, MMF, MMP, and MMR in the POA Guide

 

Advertisement

 

Business analysis Behind Proof of Concept (PoC)

We may use a PoC when the goal is to make a very small experiment around a business idea, from which we need to assess its feasibility.

A well-known way to explore ideas in an early phase of design is by conducting Design Sprints.

Business analysis work within this process is of extreme importance. First of all, a BA professional may use their facilitation skills to facilitate the entire workshop. When framing the BA scope to the ideation process, their work starts when applying the “How Might We” technique. If you want to know more about the “How Might We” technique, you can check it out here.

 

After ideating a range of “How Might We?’s, the BA work includes facilitating the following workshops, from which the ideas are refined until a (possibly very bad) prototype is built and tested with users. BAs are usually comfortable with conducting the tests. At the end, they gather the insights from the tests and assess the PoC.

 

Business Analysis Behind MVP

When planning to build an MVP, don’t forget you’re targeting and validating if a business idea, through a product, has value for customers that you believe it has. However, before investing in a solid product, the mindset is that you’re making the least effort possible to have something that technically works.

This means that the work around framing a problem and further elicitation, analysis, modelling, refinements, etc. relies on hypotheses to be validated rather than fixed requirements, allowing for greater flexibility and adaptation to changing customer needs.

 

Business Analysis If You’re Not Targeting an MVP

Sometimes, when building an MVP, it is planned in a way that has a minimum set of features that can be delivered to customers. As already discussed, that’s not an MVP but an MMF instead, so the mindset for building it focuses more on scope modelling to decide which features have to be included.

Also, if the mindset focuses more on delighting customers (sometimes disregarding the business value delivered), that’s not an MVP but an MLP instead. The BA work focuses more on user research, interviews, and partnering (if existing) with UX/UI professionals. Personas and empathy maps are commonly used techniques.

 

After that, you may define your strategy to test your assumptions. There are different techniques, which depend on the testing context. And such contexts have different approaches to use.

As a BA, we can support decision-making about the technique to choose. But also to help in setting up those tests.

 

Mentoring For Success

The year 2023 brought about significant achievements in my mentoring journey as four of my mentees successfully secured Business Analyst roles in the UK.

My passion for mentoring was ignited during my transition to the Learning and Development department at the International Committee of the Red Cross several years ago. This transformative experience marked the beginning of my dedication to fostering growth and professional development in others.

Mentoring aligns with the 70-20-10 model, specifically falling within the 20% designated for social learning. In this context, learners engage in collaborative knowledge exchange with peers and mentors, creating an environment conducive to skill development and personal growth. The 70% is designated to pivotal role of practical experience in shaping competence on the role, continuous learning by doing.  The 10% is accredited to formal learning conducted in in either in online sessions or in workshops or classrooms.

 

A mutually beneficial relationship between the mentor and the mentee characterises successful mentoring. The mentee receives individualised counsel and access to a wealth of knowledge, and the mentor finds joy in helping someone progress. This stimulating exchange fosters self-assurance, leadership skills, and a greater comprehension of one’s area of expertise. Consequently, mentoring emerges as a keystone for achievement, bridging the knowledge gap between theory and practice and enabling people to travel with direction and clarity.

Essentially, mentorship spreads like wildfire, encouraging a culture of never-ending growth and success. A mentor facilitates the growth and learning of the mentee by offering insightful counsel, encouragement, and support. The mentor’s experience and skill set serve as a beacon, providing guidance and insight along the way to success. This connection extends beyond traditional schooling, providing insights from the actual world and strengthening abilities that are frequently absent from textbooks.

 

Business analysis is a profession with a T-shaped skill set, it places strong emphasis on personal qualities. These qualities are not only crucial for success in the field but also form the foundation for effective mentorship. Key among these qualities is relationship building, as mentoring thrives in an environment of openness, trust, active listening, and the ability to provide and receive constructive feedback.

Dr. Linda Philips-Jones, in her enlightening article “Skills for Successful Mentoring,” outlines essential qualities for a good mentor, including the ability to inspire, offer corrective feedback, and, notably, open doors. I resonate with the concept of “opening doors” in mentoring, as it encapsulates the mentor’s role in guiding a mentee toward new opportunities. I prefer to frame it as showing the mentee the door, emphasizing the mentor’s responsibility to guide and support the mentee in achieving new skills and heights.

 

A mentor’s effectiveness hinges on maintaining a friendly and approachable disposition. Accessibility and availability are paramount, even in today’s fast-paced world filled with numerous commitments. Mentoring in the professional realm of business analysis involves not only imparting technical skills but also guiding protégés to succeed as consultants within the dynamic field of business analysis.

According to Memon J et al. (2015), mentorship can evolve through various life stages, including initiation, cultivation, and separation. Moreover, there may be a definition stage that facilitates the establishment of a meaningful friendship between the mentor and mentee. Each stage introduces distinct challenges and opportunities, contributing to the comprehensive development of the mentoring relationship.

 

Advertisement

 

In the context of actively seeking a role, a mentee should possess the crucial skill of effective networking, a great place to start is LinkedIn. This goes beyond using the platform solely for job searches; it includes joining industry-specific groups to acquire valuable information, knowledge, and opportunities. LinkedIn functions as a tool for recruiters to directly approach individuals for interviews. However, before initiating contact with recruiters, thorough preparation is essential. This preparation involves gaining a solid understanding of fundamental Business Analysis concepts, including requirement gathering/elicitation, analysis, and management.

 

A comprehensive approach to processes is essential, involving the ability to assess and enhance them by understanding the current state and making improvements for a better customer experience. Effective communication with a diverse range of stakeholders, both internal and external, is key, utilizing various requirement gathering methods. Identifying the right individuals to meet with and providing relevant responses often requires creating a stakeholder matrix to map those involved in the project.

Documentation plays a vital role, involving the use of process models to create organizational templates such as requirement catalogues, functional specifications, or Jira boards. Finally, extensive collaboration, active participation in meetings, and volunteering beyond one’s immediate task and job description are important aspects to contribute effectively in a professional setting.

The most gratifying moment in mentoring comes when a mentee reaches out with the news of securing a job, expressing gratitude for the support provided. While not every mentee may secure a position immediately, the success of even one mentee is deeply rewarding, showcasing the tangible results of effective mentorship.

 

Mentoring goes beyond simply obtaining a business analyst role; it encompasses on-the-job coaching as well. It aims to ensure that the mentee grasps the crucial knowledge needed to seamlessly integrate into the role. Nevertheless, many mentees appear to prefer a coach within their organization, as it accelerates their acclimatization, helps them comprehend the tacit knowledge of the workplace, and enables alignment with colleagues who can facilitate a smoother transition into the role.

As I reflect on the successes of 2023, I look forward to continuing my mentoring support to colleagues in 2024.

Prints, Processes, and Pitfalls: More Than Just Process Design!

I was recently planning the logistics of an upcoming client workshop. I needed 12 copies of a document printed and spiral bound, and I visited the website of a printing company that we’ve used many times before for such tasks. The website had changed, and unfortunately I couldn’t complete the order.  For some reason the website was saying it couldn’t deliver to my address.

 

I’m pretty sure I know why this is.  I live in Portsmouth, on the South Coast of the UK, and to the uninitiated, some Portsmouth postal codes look similar to postal codes used on the Isle of Wight. I suspect some courier firms don’t deliver to the Isle of Wight (or charge extra as it’s an island with no roads connecting it to the mainland). This leads to some online sites (incorrectly) lumping some or all of the post codes together and tag them as an ‘exception’.  This is really, really, bad design, but it definitely happens.

I was trying to place the order on a weekend, so I waited until Monday and went to contact the company by phone. I tried to phone shortly after 9, and then again at 9.30, and then again at 9.45. No reply.  So, even though I’d used this company many times in the past, I just moved on to another supplier. And in fact, I’ll probably use this new supplier in the future, too. So the original printing supplier has lost a customer and it doesn’t even know that. Plus, it missed the opportunity to get feedback about the defect on their website… I wonder how many other cities/postal codes are affected? How many other sales are being routinely lost?

 

Considering The Customer’s Pivotal Moments In Process Design

As a business analyst, this experience made me think about process and operational design. While the example above was an example of bad design, it is impossible to design an IT system, interface or process that truly caters for every situation, nor (in most situations) would you usually want to. Sure, some call centers might have a process which defines the detailed steps to take if the President of the United States calls from a satellite phone while onboard Air Force One and asks for a message to be passed urgently to the CEO… but not many!

The point here is that there will be certain types of situations that are:

 

  • Predictable, but very unlikely and/or uniquely complicated
  • Difficult (or impossible) to predict, with unknown levels of likelihood or complexity
  • Unintended, where with the best will in the world (and lots of testing) still something unexpected has happened which has led to an unintended consequence

 

The first set (predictable) are deliberately not fully catered for by a process as they are either so unlikely that spending time specifying them is overkill, or they are so uniquely complicated that anything beyond broad guidelines can’t be issued. I’d imagine that large companies have a “respond to media request” process which ensures that any inquiry from a TV station or newspaper gets to the right person. The broad process will be structured, and the response will likely be logged in a consistent way. However, how the response is formulated is probably somewhat variable, and more likely subject to guidelines and principles than a strict process. Responding to a request for a photo of the CEO to accompany a “top 10 CEOs” article is likely to be somewhat different to responding to notification that a documentary will be airing showing evidence of corruption within the company!

 

The second set of (difficult or impossible to predict) conditions can’t be catered for as they are unknown, or the effort of trying to predict them is so great that it is prohibitive.  The final set (unintended consequences) are, by their nature, unpredicted! The key here is to find them when they occur and rectify not just the individual case, but the root causes. Taking my printing example, had I got through to the first printing company, I suspect they’d have quoted me via phone and manually processed the order. Great—except the website is still faulty and swathes of other customers might be affected. Understanding what needs to change to prevent the issue happening again is key.

 

So, what aspects can be considered when designing customer journeys, IT systems and/or processes to cater for these types of situations?

 

Advertisement

 

Flexibility, Feedback and Responsiveness are Key Factors

Assuming an organization wants to handle these types of cases, it’s key to design processes with feedback mechanisms built in. Feedback should of course include opportunities for customer or user feedback, but it can also include feedback generated by the process itself.

Take the printing company example I mentioned earlier. As a nationwide printing firm, they are almost certainly finding that there’s been a minor drop in Sales (Portsmouth is a relatively big city, but probably not big enough that the drop in printing sales would ring any warning bells) and the distribution of where they are sending parcels has changed. A curious analyst diving into the data might say “hmmm, it’s odd, there are entire cities where we are no longer sending parcels… maybe we should look into that”.  Making sure diagnostic data is captured and examined is important, and this is so much more than just performance data.

It’s also important to ensure there’s a viable support option and, yes, this does usually mean ensuring someone can speak to (or communicate somehow with) a human being when they need to! That support person or team needs to have sufficient autonomy and be empowered to raise issues for investigation. A team that just “raises tickets” and passes them on to others is unlikely to cut it.

 

Finally, it’s important to note that processes will need to change and this should be expected. Building in responsiveness to the environment is important. Expectations will change, the way people communicate will change and so forth. By designing processes with this in mind, and ensuring they are owned, reviewed and adapted when needed, is a small but important step towards agility.  As BAs, we can often nudge towards this way of thinking, and every step in the right direction is a good thing!