Tag: Methodologies

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.

Unveiling the Unsaid: The Power of Subtle Stakeholder Cues

Written by Adrian Reed on April 10, 2024. Posted in Articles.

When eliciting information from stakeholders, often what isn’t said can be as significant as what is said. Of course, the information that a stakeholder explicitly mentions is of crucial importance, but often there are subtle and nuanced details that aren’t obvious unless you look for them. Perhaps a stakeholder subtly pauses and looks uncomfortable and avoids answering a specific part of a question. Or perhaps they use a qualifying word like “usually” or “sometimes”. Either way, it is crucial to probe further and find out more.

Hearing What You Expect To Hear

Looking out for these clues is important, but is easier said than done, particularly when time is tight. When there are a number of stakeholders to speak to, it is easy to get drawn into a pattern of hearing what you expect to hear. We’ve probably all experienced this: after three people from different departments outline a process consistently, speaking to the fourth and fifth person seems like ticking a box. After all, they are going to just confirm what the first three people have described, surely?

That might be the case, but equally they might have additional insights that the original three did not. There is presumably a reason that they have been selected to participate in the elicitation activities, perhaps because they have a different perspective on things. Yet, it would be easy to let those discussions be swayed by the conversations that have happened before. To almost go on ‘autopilot’ and lead the stakeholder in a particular direction. It is worth being especially aware of those subtle cues and nuances in situations like this.

An Example

Imagine interviewing a stakeholder in a finance team about the invoice payment process. You’ve spoken to other stakeholders previously and you’re pretty sure you know the process:

“So, you get an invoice in, and as long as there’s a purchase order number on there, and as long as it’s approved, it gets scheduled for payment, is that right?”

“So, yes, mainly…. Yeah, mostly that’s it.”

It’d be easy to move on from this. It would be easy to assume that they are confirming some of the key decision rules (if an invoice has a purchase order number and has been approved, it gets scheduled). But the stakeholder has added qualifying words: mainly and mostly. These are easy to miss, but definitely require probing.

Probing might go like this:

“I noticed you said that this is mainly how the process works, are there other circumstances?”

“Yes, only very occasionally though. Sometimes, we get ‘proforma’ invoices that have to be paid immediately. We have a different process for those. Also, there are some cases where we pay up front by credit card. For example, booking training and conference places. That has a slightly different process too.”

Suddenly, a whole new set of facts becomes available. If this were a real situation, this would lead to further probing (e.g. “Are there any other times when the process operates differently?”, “Is there just one corporate credit card, and if so who is responsible for it” etc, etc).

Make Sure They Feel Heard

Of course, probing this way is important to ensure that nothing crucial is missed. However, genuinely listening is important for another reason too: to ensure that people actually feel heard.

If you’ve ever had the experience of speaking to someone who appears to be preoccupied, and is perhaps presuming what your responses are, you’ll know that this rarely feels great. As analysts, it’s important that we empathize with and genuinely hear what people are saying.

Listening in this way will help uncover important information. It is a crucial and often taken for granted skill, but one that we can probably all hone and improve upon!

Connecting the Dots: The Crucial Role of Synthesis

Written by Adrian Reed on February 28, 2024. Posted in Articles.

A few years ago, I was working in a fast-paced environment where we very quickly needed to achieve a shared understanding of a particular problem that existed, and then elicit and analyze requirements for improving things.

I’d spent a couple of days speaking to some of the key people, largely in back-to-back meetings, and I was working really late in the office, energized by the conversations I’d been having. I’d managed to find an empty meeting room where I could spread my notes over a large table to think things through. Over the past couple of days I’d had countless conversations, been given documents to read, been shown IT systems, processes and more… It was a lot to take in! Plus of course not everyone necessarily agreed on the nature of the problem, or even what a desirable solution would look like. So my thoughts went to “what next… how do I arrange and make sense of all of this ‘stuff’?”

Luckily, the meeting room had a whiteboard. I instinctively started drawing the ‘problem’ that had been described to me. I drew people, IT systems, data and information flow, customer interactions, bottlenecks, problems. It was a messy drawing that wasn’t intended for anyone but me. If you’re familiar with the idea of a rich picture, it was very much like that. Crucially, it helped me make connections between pieces of information that different stakeholders had told me. This act of synthesis—bringing things together—helped gain a more holistic picture of what was going on.

I was midway through pondering whether two concepts were related to each other, when a very senior stakeholder walked through the door. He asked what I was drawing, and I talked him through my messy diagram. He started instinctively adding things to it, not only adding his perspective to the mix but also highlighting things I’d missed (or misunderstood). Even though this happened years ago, I can still remember parts of the diagram now….

Analysis Needs Synthesis

Of course, that drawing on a whiteboard was really just an interim work product. It wasn’t a deliverable, and although I recorded it by taking a photo, it wasn’t ever intended to form part of any user stories or requirements documentation. It was really just an exploration of the problem domain and the connections within it. It helped me to get my own head around the situation, so that I could ask better questions and know which areas to examine further. It also helped me to understand which areas and perspectives I was missing.

This highlights the importance of synthesis as well as analysis. Synthesis is described by the Merriam-Webster online dictionary as:

“…the composition or combination of parts or elements so as to form a whole…”

There are of course other definitions too, but this sentence is particularly useful for us as BAs. It’s very easy to think that our job is elicitation and analysis, capturing different viewpoints and pieces of information about a situation. Yet without synthesis, those different pieces of information are of limited use! There will likely be contradiction, conflict, different views and more. We all instinctively know this, but it is worth highlighting how important synthesis is in what we do.

Synthesis Techniques

Ironically, many of the techniques that we use on a day-to-day basis have synthesis, as well as analysis, built at their core. I have already mentioned a rich picture, but many other techniques (when used with synthesis in mind) can help in bringing together different pieces of information and viewpoints. Here are just a few examples:

Concept model and glossary: Bringing together (and reconciling) different terms, and the connections between terms
Process model: Creating a view on how the work should take place, taking into account a number of stakeholder’s viewpoints
Prototype: Bringing together and testing assumptions made, or a set of requirements assembled from varying stakeholders,.
Multiple Cause Diagram: After conducting ‘5 whys’ with different stakeholders, creating a combined diagram and presenting it back and saying “what else?” and “what’s wrong here?”
Workshops: Bringing people together to synthesis and discuss their views
… and many more besides

The Importance and Relevance

To do our jobs well as BAs, we need to consider synthesis as well as analysis, and this means making time for it. In my opening example, I mentioned I was working late in the office, drawing on a whiteboard. I was working late that night mainly because I was energized and excited about the project but also because time was so short and I’d focussed on planning the elicitation but less so the synthesis of the information I’d gleaned.

When you’ve conducted a whole number of interviews, read documents, seen processes and systems as they are operated, there are so many sources of information. It’s easy to just jump on to the next elicitation activity, or jump straight to writing a problem statement (or user story) or whatever. Yet, doing so robs us of the opportunity to see the bigger picture.

Building in time for synthesis—the sort that allows us to see connections—will help ensure we don’t implement a change in one area that inadvertently makes things much worse elsewhere. Of course, time is always tight… but if we don’t make time for synthesis, we might end up having to make time for rework. And that’s definitely best avoided!

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

Written by Adrian Reed on February 14, 2024. Posted in Articles.

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?

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!

Crafting a Compelling Business Case: A Practical Guide for Business Analysts

Written by David Vrbanek on February 2, 2024. Posted in Articles.

Developing a business case is akin to telling a compelling story—one that captivates your audience and persuades them to invest time, resources, and support in your idea. As a Business Analyst, mastering the art of creating a persuasive business case prior to crunching the numbers and making the pitch is essential for driving successful projects within your organization. Here are eight major points that will help you navigate the intricate landscape of business case development (i.e. “make the case”).

Basics of Making a Business Case

Let’s kick things off with the foundational principles of constructing a business case. Regardless of the nature of your proposal or the industry you’re in, the process remains surprisingly consistent.

First and foremost, abandon the idea of diving into logical arguments or grappling with intricate numbers right away. Instead, envision yourself as a storyteller, beginning with the identification of a problem or opportunity. Ask yourself: What business need are you trying to address? Once you’ve pinpointed this, it’s time to introduce the characters in your story—stakeholders, beneficiaries, and subject-matter experts.

Stakeholders, often high-ranking decision-makers, hold the power to greenlight or reject your business case. Beneficiaries are those who stand to gain from your proposal, while subject-matter experts provide insights into problem-solving. Collaborate with these individuals to explore various alternatives, considering efficiency, cost-effectiveness, and alignment with your organization’s culture.

Having chosen the best option, create a high-level project plan to estimate the time and resources required. Finally, clearly articulate the value your solution brings, setting the stage for the subsequent number-crunching phase, including ROI, break-even points, payback periods, net present value, and internal rate of return.

Learn How Your Organization Evaluates Business Cases

Understanding how your organization reviews and approves projects is crucial for tailoring your business case effectively. Answer questions such as: Does your company have a formal evaluation process? Is it connected to other processes, and how detailed do stakeholders want the information?

Leverage the knowledge of a colleague familiar with the evaluation process. In large companies, formal templates and specific review times may exist, often tied to annual budgeting. Some organizations use a “tollgate” process, where approval is sought for project phases, allowing gradual commitment of resources.

Smaller organizations follow a similar pattern, albeit with less structure. Identify decision-makers’ authority levels, and if your organization lacks a defined process, seek insights from successful colleagues who navigated similar challenges.

Know Who’s Calling the Shots

Understanding who holds the fate of your project is paramount. Whether it’s an individual or a small committee, knowing your audience allows you to tailor your case to their priorities. Your boss might have insights into the decision-makers, whether it’s the CFO, division head, or a committee representing various organizational facets.

Identify the dominant department, as their goals often carry significant weight in decision-making. Find a champion within that department or committee who can advocate for your proposal. Remember, the goal isn’t just approval but informed decision-making, even if it means rejection.

Once you know the decision-makers, understand their priorities. Senior leaders look for projects aligning with the company’s strategy, emphasizing the importance of ensuring your case dovetails with broader objectives.

Understand the Audience’s Objectives

Aligning your business case with your company’s objectives is pivotal. Begin by identifying these objectives through sources like annual reports, CEO letters, and all-staff communications. Grasp the overarching themes—whether it’s growth, cost-cutting, global expansion, or regional focus.

Those evaluating your case are likely responsible for meeting these objectives. Clearly demonstrate how your proposal contributes directly to these goals. Understand the priorities, values, and decision-making styles of stakeholders by engaging with experts from various functions and consulting your boss.

Remember, stakeholders may not always agree on how to achieve company goals, emphasizing the need to involve experts from diverse functions when building your business case.

Clarify the Need

Before delving into team-building and solution brainstorming, the business need must be crystal clear. Referred to as the “pain point,” it’s the urgent problem or opportunity driving your proposal. It could be a sales force losing bids, service desk requests falling short, or an opportunity for substantial cost savings.

Document the pain point(s) thoroughly, noting the origin, impact, and the solution’s objectives. This documentation serves as the basis for your recommendations, making it easier to present a compelling case to stakeholders later on.

Whether you identify the need yourself or stakeholders present it to you, rigorous research is essential. Document everything, keeping notes on paper or digital files to refer back to when faced with conflicting or partial information.

Build a Cross-Functional Team

Developing a business case is not a solitary endeavor. Relying solely on your perspective risks overlooking crucial aspects. Instead, assemble a cross-functional team comprising individuals from various departments and perspectives.

While you may not have a dedicated team, bring together individuals at different points in the process. Include a finance representative to provide a big-picture view of costs and benefits. Engage beneficiaries to voice their concerns and ensure a holistic problem-solving approach. If the project impacts customers, involve customer-facing representatives like account managers or customer service representatives.

External experts can offer valuable insights, whether sourced from your network, online communities, or vendors. The key is to form a tight team of experts focused on the specific case, respecting the organizational chain of command and securing support from reporting managers.

Consider Alternatives

The brainstorming phase is where your cross-functional team shines. Encourage the exploration of potential solutions, using problem statements as a starting point. Look beyond individual departments, considering how other organizations or departments might have addressed similar needs.

Emphasize that these sessions are working sessions—opportunities to generate options without delving into detailed project plans or specific vendors. Facilitate creative thinking while reminding the team of limitations and constraints. The goal is to consider all viable options before narrowing down to 2-3 choices.

Thought-provoking questions guide this process. Which option costs the least? Is it the fastest to implement? Does it have the fewest risks or bring in the most revenue? Present each option with at least one significant advantage and be ready to share rejected options and the reasons behind their dismissal.

Think Through the High-Level “How”

Paint a vivid picture of how your proposed solution will be implemented within the organization. While not a detailed project plan, this outline provides a realistic basis for estimating costs and benefits. Consider what tasks need to be done before, during, and after the project switch.

Engage subject matter experts and stakeholders in this process. Anticipate potential roadblocks and resource requirements, securing buy-in from involved departments. Validate your proposed solution with your cross-functional team, ensuring feasibility and uncovering any hidden costs or constraints.

This high-level planning stage helps you identify whose support you’ll need and ensures that all costs, including one-time expenses, are accounted for. It sets the stage for detailed financial calculations and further strengthens your business case.

Here’s to crafting a compelling case that resonates with stakeholders!