Tag: Requirements

The Strawman: When a Wrong Makes a Right

Written by Anna Rajander on June 29, 2022. Posted in Articles.

Sometimes, the easiest way to find out what someone really wants is to show them what they don’t want.

The strawman approach is frequently used by business analysts – sometimes knowingly, and sometimes not. Actively inviting stakeholders to engage with and criticize an inaccurate reflection of requirements can provide insights that greatly speed up the requirements elicitation process. However, it can also be a risky approach.

This article describes that strawman approach, its potential pitfalls, and tips for using the approach to support productive requirements elicitation.

What is the Strawman Approach?

You may have heard of a strawman argument – an argument that distorts an opposing stance to make it easier to attack [1].

In business analysis, a strawman can be created by presenting knowingly incorrect, incomplete or distorted requirements to stakeholders in order to provoke a response. This is usually done in the form of a model or prototype solution, providing a visual representation that stakeholders can engage with and refute. The idea is that the way stakeholders respond to the inaccurate strawman will inform more complete, coherent and representative stakeholder requirements.

Stakeholders often find it difficult to articulate their requirements. They can be vague when it comes to specifying their wants (I want a bright color…), yet very specific when it comes to specifying what they don’t want (…but not pink!) This is because people often find it easier to specify their wants and needs in opposition to something. In such cases, presenting an inaccurate or incomplete model/prototype representation of requirements as a strawman can provoke a strong response from stakeholders, creating a better understanding of what they don’t want, and providing a starting point for conversations about what they do want.

The Pitfalls of the Strawman Approach

While the strawman approach can be a powerful requirements elicitation technique, the approach should be used with caution. Some of the potential pitfalls associated with using a strawman include:

Impact on your credibility: When done right, presenting a strawman to stakeholders can make a business analyst appear open, co-operative, and responsive to stakeholder needs. However, presenting something that is clearly wrong can also impact a business analysts’ credibility, leading some stakeholders to question the analyst’s abilities.
The strawman becomes the answer: The point of the strawman is that it isn’t accurate! You want stakeholders to refute it and provide information that will allow you to change and/or improve it. However, in cases where stakeholders really do not know what they want, they may not challenge the strawman. This could lead to the strawman (either in part or whole) becoming the answer.
The business analyst can feel exposed: Presenting a strawman is not an easy thing to do. It takes a degree of professional courage to produce a piece of work and present it, only to have it criticized – even if that was the intention.
Some stakeholders are too nice: Some people find criticism difficult and may be unwilling to say what they really think about a strawman, particularly when they are being asked to criticize it in a group setting.

Tips for using the Strawman Approach

The following are a few tips to consider when using a strawman to elicit requirements:

Do you research. Make the ‘strawman’ as accurate as possible. Differentiate between elements of the strawman that are based on known, more accurate requirements, and those that are ‘best guesses.’
Know your stakeholders. Think about how your stakeholders might react to the strawman. Think about how you present the strawman to different stakeholder groups. Consider presenting the strawman to ‘friendly’ stakeholders 1-on-1 to get feedback to improve it, prior to exposing it to more influential stakeholders and/or a larger group.
Acknowledge it is a strawman. Sometimes acknowledging what you are presenting is a ‘strawman’ will give stakeholders the permission they need to constructively criticize it.
Don’t rely on it. The strawman approach should not be used as a primary requirements elicitation approach, but rather a tool that may be deployed to elicit those more subjective requirements, engage a particular stakeholder group, or as a check for validating what you know and what you don’t.
Clearly label your strawmen. Once in the wild, the strawman can obtain a life of its own, being reproduced and/or discussed in unintended places. Therefore, it is important to clearly label, store and/or otherwise indicate the strawman is a draft, prototype or experiment.
Don’t take is personally. Remember, the stakeholders are reacting to and criticizing what is presented to them – not you personally!

Reference

[1] Strawman Arguments: What They Are and How to Counter Them – Effectiviology, www.effectiviology.com/straw-man-arguments-recognize-counter-use/

Techniques for prioritizing requirements

Written by Aly Cassam on January 13, 2022. Posted in Articles.

One of the major challenges that Business Analysts face is getting stakeholders to prioritize requirements. Everyone is used to high syndrome – where the stakeholders say everything is a high priority.

The key to dealing with this problem is for BAs to understand the drivers of the project and then create priority evaluation criteria to assess each requirement. This is a key step that is often overlooked when starting the business analysis deliverables of the project.

Let’s say the objective of a project is to optimize a business process for an operations group. As a BA it’s important to understand what constitutes an optimized process. It’s a simple upfront question that will surface criteria that the BA can use to help the business prioritize the requirements. For example, the stakeholders may indicate that the optimal process would be one in which the To-Be process has fewer manual hand-offs, reducing the amount of paper that flows through the process, reducing the number of steps requiring manual entry of data, etc.

These criteria can then be used to develop a framework with which to evaluate and prioritize requirements. My preferred approach is what I call the scale approach. With the scale approach, you get the stakeholders to call out how well each requirement aligns with the assessment criteria on a scale of 1,3 and 5 (where 1 means the requirement is poorly aligned with the criteria, 3 somewhat aligned, and 5 highly aligned). This gives a numeric priority assessment of the requirement and a quantitative method of comparing requirements. This helps to get stakeholders out of the “high” trap mode.

Scale Approach:

Here is an example of the scale approach. The scaling approach uses a 1,3,5 scale where 1 is poor alignment, 3 is some alignment (in the middle) and 5 is highly aligned. The max score for any requirement is 15 and the minimum is 3. I’ve tried more granular approaches like 1 to 10…but it just causes a lot more sitting on the fence when you have that many values to apply to a criterion…and it’s not as “distinct” an outcome as the 1,3,5 scale. I specifically avoid using numbers instead of High, Medium, and Low because I find that a numeric approach makes things more subjective than a High, Medium Low evaluation approach.

#	Requirement	Evaluation Criteria 1 (Reduce Manual steps)	Evaluation Criteria 2 (Reduce paper through the process)	Evaluation Criteria 3 (Reduce number of manual steps)	Total Criteria Score
1	Requirement 1	3	5	1	9
2	Requirement 2	5	5	3	13
3	Requirement 3	1	3	1	5
4	Requirement 4	3	3	3	9

Typically, with the above scoring system I would then map it to the more traditional High, Medium, and Low using the following ranges:

Low – score equal to 5 or lower

Medium – score of 6 to 10

High – score of equal to 11 or higher

Based on the above you would then prioritize the requirements as follows:

#	Requirement	Priority
1	Requirement 1	Medium
2	Requirement 2	High
3	Requirement 3	Low
4	Requirement 4	Medium

Heat Map Variation:

Most stakeholders are very visual. So sometimes I’ll combine this with a heat map approach. With the heat map approach, each score on the scale is associated with a color.

Score of 1 – shade the cell red

Score of 3 – shade the cell yellow

Score of 5 – shade the cell green

So, if we take the above example and add colors, it will look like:

#	Requirement	Evaluation Criteria 1 (Reduce Manual steps)	Evaluation Criteria 2 (Reduce paper through the process)	Evaluation Criteria 3 (Reduce number of manual steps)	Total Criteria Score
1	Requirement 1	3	5	1	9
2	Requirement 2	5	5	3	13
3	Requirement 3	1	3	1	5
4	Requirement 4	3	3	3	9

As you can see above – it really jumps out at you that there is a “strong” fit with requirement 2 and a poor fit with requirement 3. I find the heat map approach helpful when there are a lot of requirements because it’s a lot easier to gauge and compare requirements based on colors than numbers. Also, a lot of times with a heat map you don’t need a total criterion score at the end. It just jumps out at you.

You can further simplify things by just using the colors instead of the numbers.

Does it take more time?

The simple answer is no it doesn’t take more time. All it takes is a little bit of prep, a prioritization meeting and then you have prioritized requirements. When you compare that to having numerous emails, meetings, and discussions about what the requirements priorities are you’ll see it’s a much simpler and effective approach. It also forces stakeholders to really think about the requirements and how they want to achieve their objectives – so less second-guessing of requirements in the future.

One final note:

When I use this approach, I put the actual scoring matrix into the appendix of the requirements document and not in the main body to enable a wider audience to more easily read the requirements document.

Turn your specifications into living, digital documentation

Written by Line Karkov on December 8, 2021. Posted in Articles.

Digital transformation requires the use of new tools and new ways of working – also for business analysts. We often facilitate this for other groups of people, and we should be ready to look at our own habits and preconceived notions as well and embrace new mindsets and tools. This article offers a take on what ways of working could look like for the digital business analyst.

Collaboration is becoming increasingly digital, and this also gives business analysts many opportunities to work smarter and better. That is, if you are ready to let go of documents and spreadsheet, and instead embrace digital tools for wikis, notes and backlog management. With a wiki tool, you can easily build your requirements documentation using webpages in a tree structure. Your first pages describe your scope. Each of those pages can then be broken into details on several pages that branch out. If you are familiar with mind maps, you will see that this is basically the same structure. In fact, a mind map can be a great first sketch of how to structure the content of the wiki.

The wiki structure allows your documentation to grow dynamically without you losing the overview. This structure is very well suited for agile development. If you focus on establishing the scope first, you will soon have some documentation that is accurate, though it is high level. You can describe the scope of your initiative first, and sign that off with your stakeholders. Based on that, you can discuss deliverables with your developers, and establish your backlog with features or epics. The features or epics can then be prioritized with your stakeholders. You can then detail out the requirements on your wiki, and the team can break down the user stories based on the wiki. This means, that while your scope is fixed and signed off, your detailed requirements get fixed and signed off incrementally in the same pace as the team is developing. I have experienced this to be a good way to be able to handle scope creep (because I have the scope to keep the requirements in check) and to avoid analysis paralysis and requirements rot. Because it is digital, I can create links from my backlog items to the relevant parts of the specification.

The basic concept can be illustrated like this:

Why not just add my requirements to the backlog items, and avoid all the linking? Well, because I want my documentation to describe my product holistically, including its context. And I want my backlog to describe the increments that the product is built in. So I need both. I can then communicate, what my product is and does without also having to communicate the increments it was built in, which is completely irrelevant to most of my stakeholders. I can easily share a wikipage with a link or present it in a meeting. This means fewer powerpoints to produce.

Once the product is built, I no longer need the backlog – my documentation is what describes the product. And with that documentation established at the very early stages of the product development phase, I can communicate what the product looks like through its whole life cycle, from the birth of the idea to the decommissioning of the product. Each page is automatically version controlled, which makes the change control much more granular, and changes easy to manage without keeping extensive change logs. In some digital tools, you can even set up approval workflows to make sure that the right people sign off on changes. I like to think of it as the DevOps mindset implemented in requirements analysis.

You can add any kind of content. A webpage has no limits when it comes to content – pictures, text, tables, links, and attachments. Your documentation can contain much more than a traditional requirements specification, such as personas, test data, samples of production data and other types of examples. Because of the tree structure, I always know which objective or process a detailed requirement supports. Obviously, various kinds of diagrams play an important role. Traditionally, you would argue that you must do your modelling using a modelling or BPMN tool. The reason for this is that your models can then be reused by others. In theory, this is true. However, I have never experienced this reuse in my 15 years as a business analyst.

Over the past couple of years, I have practiced using pen and paper for visualizations, and I have integrated this into my ways of working. It is a great way to work because it helps me focus and process information. It is also free of the constraints a computer program sets when you create digital visualizations. To my own surprise, this approach is very compatible with digital documentation. Simply take a photo or scan a drawing and add the image to the page. It can then be enriched with text for elaboration. This is particularly useful when describing scope, features or epics and application landscape. Digital and analogue are not contradictory, but complementary.

I have recently published two articles on BA Times related to using pen and paper, which provide some tips for getting started:

Start your visual facilitation journey with letters

The icon library: My favorite analogue tool

Critical Skills Needed for Project Success

Written by Elizabeth Larson on November 4, 2021. Posted in Articles.

Part 1 – Elicitation

This article is the first in a series I’ll be writing about critical skills that all project managers (PMs) and business analysts (BAs) need for success. We need these skills regardless of the type of project we’re on, the industry we’re in, the technology we use, or the methodology we follow. Each of these skills requires a combination of what are commonly called hard skills with those needed to work effectively with others.

This first article is about elicitation. It seems easy. After all, what’s so difficult about asking stakeholders questions? Elicitation, of course, is far more than the questions we ask. When all is said and done, it’s about learning. We learn what our stakeholders want, what they need, and hardest of all, what they expect by asking really good questions and listening to what they have to say with great attention. It’s tricky, though. We can’t do what I did early in my career when I tried to develop a list of requirements by introducing myself and asking what the stakeholders’ requirements were, what they really needed, and what they expected by the end of the project. Simply put, we won’t learn enough to create an end product that they’ll be happy with.[i]

What makes the elicitation process so hard? Here are several pitfalls.

Common Pitfalls

#1 – Missed expectations

Expectations are requirements, but they’ve never been stated. Therefore, we cannot get expectations by asking about them. Our stakeholders don’t think to mention them, and we don’t think to ask about them. I didn’t know about hidden requirements early in my career when I asked the questions like those noted above. Another problem– my focus was specifically on the future state solution. I asked for the features and functions, documented them, and got stakeholder approval. Then the development team built the final product according to the specifications with the inevitable result—a lot of stakeholder complaints.

#2 – People fear the future state.

This major pitfall is hard to overcome for many reasons. Some stakeholders are comfortable with their current state and don’t want to learn or train on the new processes and automation. Others are concerned for their jobs. Still others have a stake in the existing ways – perhaps they were part of its development or a known expert on its use. Whatever the reasons, the fear of the future state can make elicitation difficult.

#3 – The time trap

Many of us are often under so much pressure that we don’t have time to dig deep. We gather some high-level requirements, but we don’t have time to uncover the expectations. And even if we have time, which is rare, many of our stakeholders don’t. Many are available for an initial set of sessions, but interest wanes as the difficult detailed meetings drag on.

So, what can we do? Here are 3 tips for successful elicitation.

Tips for Successful Elicitation

Tip #1 – Use a variety of elicitation techniques

The first tip for uncovering expectations is to use a variety of elicitation techniques. That’s because each technique that we use uncovers a different aspect of the requirements. Here are some examples.

Process modeling. This has always been one of my favorite techniques. It documents how people get their jobs done. But as with all elicitation, it’s not easy. For example, one of the most difficult aspects about process requirements is that stakeholders argue over where to begin and where to end and how the processes fit together. Using different process models helps avoid this contention. SIPOCS (suppliers, inputs, process, outputs, customers) help narrow the scope of each model and swim lane diagrams help visualize how the processes fit together.
Data modeling. Process modeling is great, but people need information to get their work done. Data modeling helps us figure out what information supports each process step. It also provides business rules and is invaluable on our AI initiatives.
Use cases. These models help us understand how our stakeholders want to use the final product. They provide not only the scope, but all the functionality of the solution. And use cases, if completed thoroughly, turn into test cases.
Prototypes show what the final solution will look like.
Brainstorming yields the power of the group, while one-on-ones often reveal what stakeholders really think.

Tip #2 – Ask context questions

A context question is one that surrounds the solution that we’re building. While we do need to ask questions about the solution’s features and functions, such questions do not provide the complete picture.

I like to group context questions into four categories of questions:

These questions relate to what’s happening outside the organization and include questions like demographics, language, weather, technology, and compliance/regulatory. These may or may not apply to the project. If they do, we need to understand their effect on our work.
These pertain to how ready the organization is to accept the final product. The bigger the change, the more issues there usually are. We need to know, for example, which stakeholders will be on board, which will resist the change, and what needs to be done to prepare the organization for the change.
We need to ensure that the business problem we’re solving and the proposed solution align with the organization’s goals and objectives.
These context questions are usually those about the current state.

Tip #3 – Know when to use open-ended, closed-ended, and leading questions

Open-ended questions allow the respondents to expand their thoughts. We ask open-ended questions any time we want to learn more. For example, we ask these questions when we’re just beginning an effort, during brainstorming, and when we need to get all the issues out on the table, etc.

Closed-ended questions are forced-choice questions. They have the answers embedded in the question itself, sometimes explicitly as in a survey question, or implicitly. I like to ask closed-ended questions when stakeholders are all over the board and we need them to focus. For example, given all these issues we’ve identified, if you had to choose 10, which would they be?

Leading questions are not questions at all. They sound like questions, but they’re really our opinions stated in the form of a question. “This is a pretty cool feature, isn’t it?” My least favorite leading question is one we often hear: “Have you ever thought about…solution.” Again, it’s not a question. It’s us presenting our opinion rather than asking what our stakeholders think. What’s wrong with that? Remember we’re in the middle of elicitation, which is about learning. Presenting our solutions during elicitation cuts off exploration because we’re telling rather than learning. Later, after we’ve completed elicitation and analysis, whether it’s for the whole project or a smaller part, we can make a thoughtful recommendation.

To summarize, effective elicitation is critical to the development of a final product that our stakeholders are happy with. Elicitation is not easy. There are several pitfalls which are difficult to overcome. But if we follow the tips provided in this article, we will deliver a product that our stakeholders actually like and want to use.

[i] I use the terms solution, final product, and end product synonymously. It’s the solution to the business problem we’re solving. It’s also the product or product increment being produced at the end of the project, project phase, or iteration.

Business Analysis as A Service

Written by Business Analysis (BAPL) on October 6, 2021. Posted in Articles.

One billion dollars wasted, 100 million over budget, a 40-million-dollar initiative costing $250 million dollars! Recent announcements in the press regarding significant initiatives, projects & product overspend and minimal value, are testament to this. Successful initiatives are key to organisational success, and an effective requirements process is the key to successful initiatives. This is costing organisations millions of dollars in wasted expenditure, and many more millions in lost opportunity. If your Customer Journeys, Epics & User Stories are not correct and aligned, then your initiative is certain to fail.

A service is a means of delivering value to customers, by facilitating the outcomes customers need. Effective services start with the understanding of that need, and work towards providing the best possible outcome(s) within the customer environment. Business Analysis is a service like all others and considering it as such is important for that services success.

However, business analysis is a broad service offering that can cover anything to do with innovation, people, process, and technology. In addition, the customers of Business Analysis also vary including Product Managers & Owners, Developers, Testers, Solution Architects, all the way through to CIOs, CEO, and Company Directors.

What is Business Analysis as a Service?

Why not have your business analysis serviced like you do your car?

When your car needs a service, you book it in, arrive, hand over the keys, return later that day, pay and drive home. You trusted the dealership to do what you paid them to do, service the car.

You never asked for a specific mechanic, you never asked for a subject matter expert, all you wanted was for the service to be completed, the logbook to be signed and to have a checklist of the agreed work that was performed. No hassle, all done.

The way you and your internal customers (Product Owners, Project Managers, Development Leads etc) receive business analysis should be no different. You should have the confidence and expectation that you will receive the right outcomes to drive the initiative in the right direction.

When your business needs analysis, you book it in with us, you return later, pay, and receive the agreed outcomes. You can trust BAPL to do what you paid us to do.

You never need to ask for a specific consultant, we engage with your SME’s, you never need to ask for special requests as we scope and identify the requirements to the appropriate levels, highlight any risks or assumptions and deliver the agreed outcomes, bringing value for money, in shorter timeframes resulting in improved initiatives. No hassle, all done. It’s called Business Analysis as a Service, and our service is second to none.

In a Business Analysis as a Service model, we work in collaboration with you and your internal customers to establish the required services needed to deliver the analysis for the organisation’s improvements to their products and services. We would understand the need, define an appropriate approach, set timelines etc.

This provides an opportunity to identify the competencies and capabilities required to fulfill this need. The assigned BAs would work develop an approach and delivery plan, provide consistent reporting to ensure the agreed upon outcomes are being delivered, and to manage any issues that may be putting these outcomes at risk.

This model puts the accountability of business analysis outcomes back to the BA Team and BA Manager, rather than on the shoulders of the individual or the team they are working in. In doing so, it provides the BA Team Manager the ability to forward plan resourcing, forward plan capability uplifts, and assign the right person to the deliver the right service. This results in the right service, delivered in the right time, with the right analysis, resulting in better outcomes for your organisation.

This model works in both small and large team environments, agile and waterfall.