Skip to main content

Tag: Communication

Web 3.0: The Future of Process Catalogue Management?

Web 3.0 technology, in my view, can be used for new innovations and has the ability to deliver positive change quicker. Specifically, Blockchain technology could allow for a transparent, automatic and secure way to manage a business’ process catalogue.

Traditionally, when analysing processes things like Upper/Lower Specified Limits, Service Level Agreements, and Defects Per Million Opportunities are used to understand whether a process is performing satisfactorily. This requires a BA to take measurements, validate them and then work with the business to pivot the process back to delivering the agreed standard. The typical business trigger event for this is either automatic or internal– it requires a BA to pick up during routine quality testing, or an actor to notice and raise through an agreed mechanism. This is because the process infrastructure is basically storage; it could be coined as “static management”. This means things can be missed, as humans make mistakes and the data does not work for the business, rather the business works for the data.

There have been recent advancements in technology, namely Web 3.0, which can reduce or potentially eliminate the human error element and turn the process catalogue into a dynamic storage, in which the data works for the business. In particular, Blockchain technology offers several features that could transform the way we work.

A Blockchain has several features, such as: Nodes, Ledger, and Wallets. Nodes are users/devices that hold the ledger, in full or in part. The Ledger is the record of transactions that happen across the blockchain and wallets are areas, in crypto blockchains, where the cryptocurrencies are stored.

 

At a first glance, this ecosystem seems locked to currencies, I believe it can be adapted to handle processes. Each process would need to be broken down into its steps and identified by its inputs/outputs and business actors. This dataset is then integrated into a blockchain – with each block containing the data from a single process step. In terms of a traditional process map, the block is the process step and the transaction is the connector lines between two process steps. In process terms it would be Step, Connector, Step; in blockchain terms it would be Block, Transaction, Block.

When the process is run, new unique blocks are added to the chain with the details of that unique process step run, which are then linked to further blocks/steps via transactions, providing a completely transparent and auditable record.

 

This setup has an infrastructure advantage because a blockchain validates transactions through decentralisation, using other blocks already in the chain. It means process rules are embedded in a chain from existing blocks and are then used to validate new blocks, resulting in a guaranteed uniformed process run, as the blockchain would only validate the transactions in accordance with the blocks already there.

The blockchain allows for easy performance monitoring, as each block is recorded with management information as well as process information and this is all in one place, it is easy for an analyst to calculate run times, business actor performance on individual or multiple transactions and process efficiencies.

Once an improvement is identified, the process is updated and released onto the blockchain, then becoming the single-source-of-truth for transaction validation, therefore only allowing the most up-to-date process to be followed by business actors. In this sense, the blockchain is both the governing authority as well as storage for processes.

 

The problem with this is that it is still reliant on humans picking up on the fact that a process is not performing, so whilst we have an enforceable process level to six sigma, we do not have the benefit of removing the human error or time lag associated with a drop in process performance.

This can be resolved using a feature of a blockchain called a smart contract. Smart contracts are automated digital contracts which trigger when the terms and conditions of that contract are met. There is an equivalent document in the business world, which sets out an agreement between two parties to perform in a particular way or to a particular standard under particular terms – a Service Level Agreement (SLA).

The smart contract is the Web 3.0 equivalent to the SLA. However, a smart contract offers much more than just an agreement, it self-executes which means as soon as the terms are met, action is taken with virtually no time lag.

 

Advertisement

 

The smart contract is created using an if/when then statement. An example smart contract can be if a customer makes an enquiry and no one contacts the customer in 3 working days, then an escalation notice is sent to the assigned persons manager. As this is automated, as soon as the condition is met, the contract is acted upon – meaning management do not have to spend time reviewing whether the conditions within SLAs, making both service and personal performance management easier.

There are, however, some issues with blockchains which need further consideration to overcome: a large number of transactions can cause lag on the chain, due to the required effort to process them all, meaning slower transaction times. It may mean that this model is best suited to small startups/businesses. Blockchain technology is still new, and therefore is not thoroughly regulated yet, meaning it can be difficult to fit in with current governance structures. This can be tackled by robust risk management and future legislation or policies, meaning this model may be suited to an innovator type business.

 

In summary, Web 3.0 Blockchains can offer improvements to the operation, governance and management of processes. By leveraging features of blockchains, it’s possible to move from a static process catalogue to a dynamic, automatic and smart infrastructure which reacts quicker to changes in business environments, freeing up staff to find other efficiencies or grow the business in other ways. While there are concerns and issues around things like scalability and regulations, it is clear that Web 3.0 technologies can offer new and exciting opportunities.

The Mind as the Canvas

In the ever-evolving world of business analysis, the ability to convey complex data insights and concepts is paramount. For many, Visualization is a fundamental tool, often associated with software applications such as Power BI, Tableau, or Excel. In these tools an image containing all data points is generated for visual consumption and interpretation.

However, for Business Analysts who are certified with Sight Loss, this traditional approach of transcribing an externally generated image visualization into the mind can present a barrier to conducting their duties. In order to overcome these barriers it is essential to embrace non-visual representation, not only to ensure the Business Analyst with Sight Loss can complete their job, but by doing so it also develops and encourages many other benefits for the entire business.

 

Using a traditional Visualisation method, namely consuming and transcribing an external image into the consumers mind for analysis and interpretation, presents significant challenges for those who cannot access the external image in the first instance. Visualisation is an internal process and we use external stimuli to reconstruct this in our minds. These mental images can be real or imaginary, for example if I ask you to think of a pink elephant, you can do so, despite it not existing. The objective of having a pre-generated image to transcribe is one of time saving through consistency. By having technology that converts non-visual data into a visual image saves the user from having to do this themselves. Further, it also ensures that every consumer of the image has the same input and is therefore the internal process goes from reconstruction to transcription.

 

Think back to the pink elephant, if two people had to imagine it and compare, there would be differences in the size of the elephant, the ears, the hue of pink, and many other variables. Any question raised by the variability can be removed when transcribing, because you do not have to think about the construction of the image just the result of the image.

 

It is therefore logical to conclude that the essence of visualisation lies in cognitive processing and data communication methods. The communication method traditionally gives a visual representation before entering the mind, which is usually accepted by the brain as fact. There can be no more clearer way to draw out the problems of this than the recent phenomenon of the Changing Dress, which appears either Blue and Black or White and Gold to different people. Both versions are subjectively true. We accept pre-generated images to be true because of various reasons from the size of the dataset the image has been generated from, to the relationship between stakeholders, to the attitude and aptitude of the Analyst.

 

The concept of non-visual data representation is a crucial avenue for enabling not only Analysts with Sight Loss to excel in their roles, but to ensure that the risk of incorrect data insight is minimised.

 

Advertisement

 

There are several benefits to not relying solely on a pre-generated image. Firstly, enhanced data comprehension, namely non-visual data consumption that relies on auditory, tactile, and textual methods to convey the knowledge of data as data points, not visual graphics. Utilizing alternative communication methods can allow access and interpretation of complex datasets in a new and engaging way. This approach allows for a deeper understanding of the data, in the same way that reading a book cover-to-cover (i.e. the dataset), instead of just the blurb (i.e. a pre-generated external image) gives a fuller understanding of the content.

 

Secondly, when presenting findings to stakeholders, it can be beneficial for them to understand it not in a mental-visual aspect but as data points, facts, and relationships. This includes verbal descriptions, accessible documents, audio tracks and storytelling (as opposed to story boarding). By doing so, analysts can articulate their insights clearly and persuasively without traditional visual aids or statistical jargon. It can also enable the stakeholders to engage more effectively with the data and can apply their own domain knowledge, further helping the project being undertaken.

 

Thirdly, for those BAs with sight loss, the advancement in technology means that they can process data more effectively with Screen Reader software and tactile graphics, building a graph in the mind. Much in the same way that following instructions on Google Maps and actually walking the route, are two very different experiences. These tools can provide real-time feedback and enable analysts to explore data, scenarios, and outliers effectively, all while maintaining the focus on the data itself, instead of interpretations of data.

 

Fourthly, a further benefit of non-visual communication is increased collaboration and teamwork.  Non-visual communication allows analysts to work seamlessly with both sighted and colleagues with sight loss, to share their findings, develop requirements, and craft compelling data narratives, centred on the concept or data’s intrinsic qualities.

 

Further to these benefits, non-visual communication can encourages innovative problem-solving techniques, because it does not funnel people into thinking visually, it does not bias them towards any particulars, by predisposing them to the stimuli of a pre-generated image. Analysts with Sight loss can apply their unique perspectives to explore different approaches and scenarios, contributing valuable insights to the analysis process without relying on visual cues.

 

In conclusion, within the realm of business analysis, non-visual processing is crucial for individuals who have sight loss to equally participate, but it can also present business-wide benefits. Embracing non-visual approaches empowers all staff members of an organisation to excel in their roles, offering enhanced data comprehension, alternative communication, and adaptive problem-solving techniques that focus on the data itself, not a pre-defined notion. As we strive for inclusivity and diversity in the workforce, it is essential that the business analysis field acknowledges the value of non-visual processing and provides the necessary support and resources for Analysts with Sight Loss to thrive.

 

In doing so, we ensure that all individuals, regardless of their Sight capability, have an equal opportunity to contribute their skills and insights to this dynamic field, with the primary focus on processing as the valuable core of their analysis.

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.