Tag: Best Practices

Don’t Let Your Software Requirements Die

Written by Chris Rickard on April 11, 2024. Posted in Articles.

In the realm of software development, the clarity and accuracy of software requirements are pivotal for project success. Traditionally viewed as static documents to be archived post-project, this perspective neglects their ongoing potential.

Living software requirements is a paradigm where these documents evolve continually with the software, serving as an enduring source of truth. This approach not only maintains relevance but also actively shapes the software’s lifecycle, promoting adaptability and precision in development processes.

They ensure that as software grows and changes, the documentation is not left behind, thus avoiding the pitfalls of outdated or irrelevant information – because often zero documentation is worse than out of date documentation!

How requirements slowly die.

Picture this: a new software project kicks off with energy and optimism. The business analyst dives deep, engaging with stakeholders to gather an amazing set of requirements. They craft an impressive functional specification that serves as the project’s North Star, and as the project kicks off, hundreds of tasks get populated into a project management tool like Jira, mapping out the journey ahead.

The software delivery team starts strong.

As expected, questions and clarifications emerge, evolving the requirements a little. Some tasks need tweaks; others have missing components, and there are even some sew requirements that surface. This is fine (we are agile after all!) – and these changes and additions are all added into the project management tool, as that’s now the source of truth keeping the project on track.

As the tasks are ticked off, a sense of accomplishment fills the air. Finally, the project crosses the finish line, the board clears, and it’s a wrap. Success!

Or is it? Software, particularly the large, mission-critical kind, is never truly ‘done.’

The project may have ended, but the software lives on, continuous adaptation and enhancement are normal these days. But scoping new tasks becomes a little harder, as the detailed system knowledge from that original functional specification, has now changed. The source of truth is now fragmented across completed Jira tasks and buried in comment threads.

In this scenario, the requirements didn’t just become obsolete; they died a slow death, leaving the team navigating a labyrinth of past decisions and discussions to grasp the full scope of their own software.

How to keep my requirements alive?

Keeping software requirements alive is pivotal for the long-term health and adaptability of your system. Rather than relegating these crucial insights to a static document, consider embedding them within a collaborative platform accessible to the entire organization. This living, breathing approach ensures that requirements can evolve alongside your software, reflecting real-time changes and decisions. Here’s how you can make it happen:

1. Centralize requirements and allow collaboration: Choose a platform where stakeholders across the business can access, review, and iterate on the requirements. This system should be the go-to source for everything related to what your software does and why, and platforms such as Userdoc are specifically tailored to this task.

2. Project management integration: While the main body of requirements should live outside, ensure there’s a seamless flow of information into your project management tools like Jira. This helps in translating the high-level requirements into actionable tasks and ensures day-to-day activities align with the broader goals.

3. Continuous updates and iterations: Encourage a culture where updating the requirements is part of the process, not an afterthought. This keeps the requirements current and relevant throughout the software lifecycle.

4. Embrace AI – AI can be an amazing tool for helping determine what changes could affect other parts of your system, and understanding that when writing requirements for New Feature X, you will also need to update Existing Feature Y’s requirements.

5. Requirements versioning: Just like with code, software requirements need versions and branches. Ensure you clearly denote what features are live, what features are in development, and what features are still being scoped.

6. Living reference for all teams: From development to QA, from business analysts to project managers, ensure that everyone references and contributes to the same set of requirements. This alignment prevents information silos and fosters a unified understanding of the system.

7. Long-term business asset: Beyond project completion, maintain these requirements as a living record of what’s in place. This becomes invaluable for training, onboarding, and new developers understanding the system’s capabilities and limitations. It also ensures the source code isn’t the only source of truth for the system’s functionality.

Transforming your software requirements into living documentation is a strategic move that pays dividends throughout the lifecycle of your software.

And the thing is, it’s not actually doing any extra work – it’s just simply unifying the place where that work is done, and fostering a culture of continuous collaboration and documentation.

Embrace the concept of living software requirements and watch your software, and team, move faster with more confidence.

Web 3.0: The Future of Process Catalogue Management?

Written by Adam Pearson on March 27, 2024. Posted in Articles.

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.

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.

“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.

The Mind as the Canvas

Written by Adam Pearson on March 20, 2024. Posted in Articles.

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.

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

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.