Skip to main content

Tag: Elicitation

A Business Analyst/Project Manager Guide to Untangling the Technical/Process Debt Mess

Usually, there would be a discussion about how only IT Business Analysts encounter technical debt as it is a Code Mess. Regardless of the industry you are working in, it may be something other than a technical debt. Still, when you are working on projects that can contribute to a similar concept or backlogs that were cleared to meet deadlines or immediate requests but weren’t cleared the right way, it is referred to as a process debt. Technical debt is specific to code, but accumulating debt from shortcuts applies to any project. Process debt refers to problems created by rushed or incomplete work outside of coding. Both technical and process debt can hinder future progress and require additional effort to resolve.

 

Who are the Culprits of Technical/Process Debts?

Truthfully, there isn’t one specific culprit, as fingers should be pointed at the project managers, business analysts, developers, and business stakeholders; hence, there is shared blame. By working together and understanding the long-term costs of technical/process debt, teams can make better decisions about how to build software, products, or projects.

 

Is Technical/Process Debt in itself a bad thing?

In some situations, technical debts can be a strategic decision to get a product or a feature out the door as quickly as possible. This might be because of need, deadlines, unclear or evolving project requirements, or even resource shortages. In this scenario, it might not be a bad thing in itself, but the key is to be aware of whatever debt accumulates and ensure a strategy to pay it down eventually. It becomes bad when it isn’t fixed and becomes the norm.

 

Another question would be, what is the role of Business Analysts and Project Managers in the Debt Den?

We exist as a bridge between business needs and technical realities. Why, as a bridge, most of us do not write the codes, but the individuals who do are part of our key stakeholders. We must keep them on track to slash the technical debt to its bare minimum until it is non-existent. By acknowledging that everyone can contribute to a project’s “debt,” teams can work together to prioritize quality and avoid shortcuts that create problems later.

Advertisement

 

What are some reasons for a quick fix that could lead to the accumulation of technical/process debts?

Deadlines (Realistic/Unrealistic): This is usually the primary cause of debts. Truthfully, some of these deadlines may be unrealistic, and some might even be realistic. Still, before deadlines are fixed for every task in a project, business analysts must have estimated the effort required for every feature/product/process. This estimation should have considered the complexity of such a task, possible roadblocks, stakeholders’ expectations, and risks. If this estimation isn’t done appropriately, unrealistic timelines or deadlines might be created. Another focus would be a dependence on Speed versus quality. In an ideal world with realistic deadlines and processes, there would be no need to cut corners; however, cutting corners is almost unavoidable when the pressure is on delivery by a specific date. In code writing, developers should have ample time to write clean, well-documented code that’s easy to understand and modify. But under pressure, corners are cut. Code becomes spaghetti-like, with functionality prioritized over readability and maintainability. This makes fixing bugs and adding new features later much more complex and time-consuming.

Solution:

Proper time estimation and setting realistic deadlines, allocate buffer time in project schedules to account for unforeseen issues or delays, allocate dedicated technical/process debt cleanup sprints, or integrate small improvements into regular development cycles and existing business processes.

 

Unclear or evolving project requirements: If the requirements are ambiguous or not well-defined, this could lead to technical debts. The business analyst’s role is to ensure the requirements are clearly identified, verified, validated, and accurately prioritized based on business value and user needs (other prioritization criteria exist). Potential relationships and dependencies are also expected to be accurately identified. When this is correctly done, it ensures that the project scope is clear and the project direction is visible to all.

Solution:

A proactive requirement-gathering system is recommended where early and frequent stakeholder involvement exists in the project/software development lifecycle. Different elicitation techniques can be used, but regardless of which technique is used, there must be a comprehensive understanding of needs and expectations. Also, remember that features or requests must be based on business value/user need/impact, not sentiments.

 

Absence of code/process reviews: This would serve as a quality check to ensure that inefficiencies and errors do not exist. Code reviews act as a safety net, catching bugs and potential issues before they become significant problems. Inexperienced developers are more likely to make mistakes that can introduce bugs into the codebase. Also, if processes aren’t documented or reviewed, they can be applied inconsistently across the team. This can lead to confusion, errors, and wasted time.

Solution:

Code reviews by senior developers can catch these errors early on, preventing them from becoming more significant problems and leading to a cleaner, more maintainable codebase. This reduces bugs, improves performance, and makes future development more straightforward. For processes, reviews provide a structured way to identify bottlenecks, redundancies, and areas for improvement within workflows. This allows teams to address these issues and streamline processes.

It is essential to state that Code/Process reviews should be seen as a learning opportunity, not a blame game. A positive and collaborative review environment encourages open communication and helps team members feel comfortable asking questions.

 

Conclusion

Technical and process debt doesn’t have to be a burden. By equipping yourselves with the right tools and strategies, you, as BAs and PMs, can become champions of clean code and efficient processes. You can expose these debts, develop a plan, and work together to build a robust and sustainable foundation for your projects. Remember, a little planning today can save a lot of headaches tomorrow –  so go ahead and untangle that debt mess!

Key Documentation Prepared by Business Analysts

Documentation is the core part of the business analysis process that provides clarity, standards, and process details that help organizations in decision-making. The documentation provides information about the guidelines, requirements specifications, roadmaps, communications, blueprints, and solutions that are crucial for the execution of the project.

Business analysts create various documents to translate complex requirements into accessible language that can be understood both by the technical and non-technical staff of the team. Business analysts bridge the gap between the business stakeholders and the technical team by creating various documentation that provides clear, concise information on the problem statement, business objectives, key requirements, restrictions, exclusions, and solutions that help in the alignment of the team.

A well-crafted document by the business analyst helps the organization secure the budget required for the execution of the project and forecast any risks during the implementation of the project. Documentation also helps to align the project with the overall organization goal and describes the value added to the organization goal by the execution of the project.

 

Key Documentation Prepared by The Business Analyst

  1. Business Requirements Document (BRD):

The business requirements document is one of the most common documents that is prepared by a business analyst. BRD captures the big picture of the project and stakeholders’ business needs. It provides detailed information on the project goals, objectives, and approved solutions, along with the key deliverables that define the scope and associated benefits of the project’s execution.

Although the fields in the BRD change from organization to organization, here are the key fields in the BRD document:

  • Project details

The project details section includes information such as project name, project number (if applicable), organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.

  • Project Overview

The project overview provides high-level project objectives and their benefits. This is the section one would read to get the complete summary of the project.

  • Project scope and out-of-scope items

The project scope lists the deliverables of the project; this helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.

Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.

  • Assumptions

The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.

  • Current and future state business processes

The current state of the of the business process depicts a snapshot of the current state of the organization, and the future state highlights the deliverables of the project.

This section helps to have a side-by-side comparison of the enhanced functionality that will be achieved by the project.

  • Business requirement

The business requirement is the main section of the BRD. This section lists all the action items that are required to achieve the project scope.

Along with the action items, it is important to assign priority to each item, as it helps the technical team identify which task they need to pick first.

For projects where the implementation of the business requirements is divided into multiple releases, it is important to include release details in the business requirements section.

  • Business rules

The business rules section consists of all the project-relevant business rules that were agreed upon and approved by the stakeholders. Business rules usually trace back to business requirements.

  • Project risks

The project risks section includes all the risks identified and mitigation measures for the risks. Identifying the risks ahead helps the team focus on their tasks and reduces uncertainty during the execution of the project. Identifying risks earlier also helps to make better business decisions.

  • Cost-benefit analysis

Cost-benefit analysis is the last section of the BRD. In this section, you describe how the project objectives will make a profit for the organization and estimate the ROI that can be achieved with the execution of the project.

 

Advertisement

 

  1. Functional Requirements Document (FRD):

The Functional Requirements document provides information about the business problem and approved solutions for the problem. FRD is the contract between the business and the technical team to deliver the accepted solution. It provides information about key functionality that a solution system needs to have and the performance of the system. FRD captures all the nitty-gritty information about the solution product.

The FRD document is different from the BRD , as FRD focuses more on the nitty-gritty details of the solution and BRD focuses on the broader view of the overall project.

The style and fields of the FRD document change from project to project. Here are the key fields of the FRD document:

  • Project details

The Project Details section includes detailed information about the project, such as project name, project unique number, organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.

  • Project Description

An overview of the project, its benefits, and the approved solution. This is the section one would read to get a complete overview of the project.

  • Project Background

The project background describes the problem statement of the project and the purpose of the project.

  • Project scope and out-of-scope items

The project scope lists all the deliverables of the project, including the technical details of the solution system. This section helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.

Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.

  • Assumptions

The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.

  • Functional requirements

The functional requirements section describes what the system must do. Functional requirements must be drafted in a way that provides complete information about the business needs and specifications needed in the solution system.

  • Operational requirements

The operation requirements section describes how the system must operate, i.e., how fast the system should respond, how many responses the system needs to provide in the given time, etc.

  • Requirement Traceability Matrix

The requirement traceability matrix is described in detail in the section below.

The requirement traceability matrix is used to track the implementation of the functional requirements. The RTM is updated throughout the project to show the progress made in the implementation of the functional requirements.

  • Glossary

List all the business terms and their definitions.

 

  1. Non-Functional Requirements Document

The non-functional requirements document defines how the system must behave. This section is crucial for the execution of the project; it describes the capabilities of the system operation and its constraints. Non-functional requirements provide information about system users, scalability, operation, hardware and software, performance, retention and capacity, accessibility, and security.

The solution system can still operate by just executing the functional requirements, but it might not meet all the business expectations in terms of security, performance, scalability, etc.

 

Below are the fields that are going to be part of the Non-Functional Requirements document:

  • Security

Security is the most important section of the non-functional requirements document. This section captures all the security guidance that needs to be incorporated by the project execution team during the implementation of the project. It captures security architecture guidance, authentication, data security, risk management, and technology development guidance.

  • Users

This section provides information about the business expectations for the number of users that will use the system. And a number of concurrent users that the system can support without letting the system performance degrade.

  • Scalability

This section captures business expectations for the data volume that the system must support. It also captures the volume that the system can support during peak and non-peak times.

  • Operational

The operational section is different from organization to organization; this is the section that captures the Tier 1, Tier 2, Tier 3… (Severity 1, Severity 2, Severity 3…) incidents that arise and the action plan to resolve the incidents. Based on the severity of the incident, a recovery strategy is defined to get the system back up and running.

  • Hardware and software

This section includes information about any new hardware components required for the execution of the project and the specifications of the hardware components.

It also captures any new software installation or software configuration required for the completion of the project.

  • Performance

The performance section answers questions such as how fast the system needs to perform. What should be the response time of the system?

  • Retention and capacity

The retention and capacity section captures data types that need to be stored in the database and the data retention time frame required for the data. It also talks about the capacity of the database and the various logs that will be available.

  • Accessibility

This section captures information about who can access the system and the minimum requirements for accessing it.

 

 

  1. Requirement Traceability Matrix

The Requirement Traceability Matrix is the document used during the implementation of the project to trace the requirements to its test cases and further to any defects. The main purpose of this document is to prove that all the requirements have been successfully executed and tested by the project execution team.

The requirement The traceability matrix generally consists of the following fields:

  • Requirement Number

The requirement number is the business requirement or the functional requirement number that is captured in either the BRD or FRD document based on organization standards. All the requirements for the project are listed in this column.

  • Requirement description

A brief description of the requirement.

  • Test case number

The test case number is the unique number used to identify the test case for a particular requirement.

  • Testcase description

A brief description of the test case and its scenarios.

  • Test execution result

This section captures if the test case was a ‘Pass’ or Fail’ during the execution of the test case.

  • Defect number

If the test case execution fails, then a corresponding defect is created, and this section captures the defect’s unique number.

  • Defect Status

This section is used to capture defect status such as ‘Open’ or ‘Complete’. This helps to know if the defect was successfully fixed and tested.

 

Conclusion

Throughout this paper, we have discussed various documents prepared by a business analyst that play a crucial role in the project’s success, driving communication and streamlining the process. From the initiation of the project to the implementation and final deployment of the product, these key documents guide the team through the project lifecycle and ensure the team is aligned with business objectives at every step of the project.

How Product Discovery Deals with Requirements

If you are working in products, you certainly have realized product management handle requirements differently. There is a shift from eliciting stakeholders’ wishes to discovering better and faster ways to solve stakeholders’ problems. This article presents how discovery techniques popular within product management fit in the three types of requirements: business, stakeholder and solution. Understanding where the techniques fit in this spectrum will allow a better understanding of how and when to use them.

Keywords: Requirements; Elicitation; Product discovery

 

What is Product Discovery and this “Modern” Elicitation

There may have been times in the past where business analysis was (incorrectly) seen as a passive discipline.  Some might have viewed that a business analyst’s job when “gathering” requirements, most of the time, was attending meetings where they interviewed a group of people. Typically, these people had significant roles in the product (although most of the time they wouldn’t be the future users of the solution) and the business analyst would simply be a clerk and register all their dictated “wish list” items.

This approach is based on the premise that your sources know what they need and dictate the solution, yet how often is this actually realistic?  More often there will be experimentation, change and the need for flexibility. The emergence of agile development methods and frameworks like Dual Track Agile, influenced organisations to split their efforts into product discovery and delivery.

 

The main shift on the premise of product delivery, compared to bespoke or market-driven requirements engineering, is that teams have to discover what the user’s problems are based on a set of assumptions and validate if a delivered solution contributes to the desired outcome. For business analysts, this means being involved in both the discovery and delivery processes, and it requires a shift in how requirements are elicited and managed. BAs need to challenge stakeholders’ perceptions on any assumed solutions and get to the underlying need using modern requirements techniques. They have to discover the requirements rather than gather them.

 

The Requirements Engineering Cycle

The cycle that typically involves elicitation, documentation, validation, and management of requirements is often associated with the broader field of Requirements Engineering or Requirements Management within the context of software development or project management. This cycle is iterative and continuous throughout the project lifecycle. Here’s how it works:

  1. Elicitation: Requirements are gathered from stakeholders, users, and other relevant sources. This step involves understanding their needs and expectations for the software or project.
  2. Documentation: The collected requirements are documented in a clear and comprehensive manner. This documentation can take various forms, such as a Software Requirements Specification (SRS), user stories, use cases, or other requirement documents.
  3. Validation: The documented requirements are then validated to ensure that they accurately represent the stakeholders’ needs and are feasible to implement. This involves checking for consistency, completeness, and correctness of the requirements.
  4. Management: Throughout the project, requirements are actively managed. This includes change management to handle updates or modifications to requirements, traceability to link requirements to design and testing, and prioritization to determine which requirements are most important.

The requirements process doesn’t end after the initial elicitation, documentation, and validation. It’s a continuous and iterative cycle because requirements may change over time due to evolving project goals, stakeholder feedback, or other factors. Therefore, effective management of requirements is essential to ensure that the project remains aligned with its objectives and stakeholder expectations. It often involves feedback loops, revisions, and ongoing communication with stakeholders to refine and adjust requirements as needed throughout the project’s lifecycle.

 

1.    Discovery Techniques for Elicitation

“How might We…” Technique

The “How Might We” technique is a crucial aspect of the design thinking process and is often used in design sprints to frame problem statements and generate creative solutions. The “How Might We” technique involves rephrasing challenges or problem areas into open-ended questions that invite elicitation through brainstorming and creativity. The challenge is to rephrase it as an open-ended question that begins with “How might we…?” The “How Might We” statements invites participants to generate creative ideas without feeling restricted by existing limitations. It shifts the focus from problems to possibilities, and it helps teams explore solutions from different angles, often leading to innovative and unexpected outcomes.

 

Jobs-To-Be-Done

“Jobs-To-Be-Done” (JTBD) encourages us to appreciate why a product or service was “hired”, not only in a functional dimension, but also in circumstances and emotional dimensions.  The book “Jobs to be Done – Theory to Practice” by Anthony Ulwick describes a framework that you can use to define your jobs, from setting your different customers, the different kinds of jobs (core, related, emotional, consumption chain and purchase decision jobs), and setting the desired outcomes.

The behaviours of the customers that afterwards lead to definition of the “hired” job are identified by observation. Observation is a common elicitation technique. In this case, rather than observing (or shadowing) in order to replicate a given process, an observation within JTBD aims to relate a behaviour to customer’s outcomes.

 

Continuous Interviews

Teresa Torres described a set of “continuous discovery habits” to engage customers in a continuous cadence. The main shift in doing interviews is that questions don’t focus on what customers want. Rather, questions should focus on their past experiences to discover an opportunity.

As the name states, it uses interviews techniques. Once more, a very popular way to perform elicitation. As mentioned, the main shift is that questions that are asked focus on their past experiences to discover an opportunity.

 

The Mom Test

the Mom Test is another interesting approach for conducting stakeholder interviews. It has similarities with “Continuous Discovery Habits”, as the questions should focus on their past experiences to discover an opportunity. The premise of the Mom test is: your mom will always like your idea, but doing the right questions can make her tell what you really need to hear. Elicitation by performing these kinds of interviews allows us to depict the problem in question, rather than waiting for the interviewees to tell us the solution they want.

 

Advertisement

 

2.    Discovery Techniques for Analysis

Value Proposition Canvas

The Value Proposition Canvas is a strategic tool used in business and product development to understand and communicate how a product or service creates value for customers. It’s typically used in conjunction with the Business Model Canvas to create a holistic view of a business. The canvas helps businesses design their offerings by gaining a deep understanding of customer needs and how their products or services fulfil those needs.

It demonstrates a clear understanding of customer pains, gains, and jobs to be done, and introduces alignment of the pain relievers, gain creators, and product(s) benefits.

 

User Journeys

User journeys, also known as customer journeys or user experience (UX) journeys, are a product discovery technique that originated from the field of User Experience Design (UXD) and User-Centered Design (UCD). User journeys provide a visual representation of the user’s interactions and experiences while using a product or service. They aim to capture the user’s perspective, emotions, actions, and touchpoints across different stages of their interaction with the product.

 

 Opportunity Solution Trees

Opportunity solution trees are a visualisation of potential solutions to a customer problem. They involve breaking down the problem into smaller opportunities, generating multiple solutions for each opportunity, and then evaluating and selecting the most promising solution.

It is our analysis work in getting insights from conducting the Continuous Interviews, allowing us to identify opportunities for our product.

 

 

3.    Discovery Techniques for Documentation

Epic Alignment

Epic alignment” is from Nils Janse’s book with the same name, proposes a single source of truth about the requirements, in form of a “lightweight” documentation that is based around epics. The structure that is proposed for this documentation includes information that is incrementally added to what we know about a given epic throughout the product development stages (namely, Ideation, Discovery, Prioritization, Refinement, Development and Testing). The structure of these documents allow to follow the information about an epic, which user stories are included, and the details that are needed for their implementation.

 

4.    Discovery Techniques for Validation

User story mapping

The last technique I want to discuss in the article is user story mapping. This is a technique where team members collaboratively discover how a set of user stories solve a customer problem. The method consists of sequencing the user’s activities, and allows further elicitation to take place so that detailed stories and tasks can be captured. This in turn ensures that the solution will  support the user’s activities that were presented.

Classifying this technique in a single stage can be tricky. I rather believe it encompasses elicitation, analysis and validation of requirements.

It’s a technique where team members collaboratively discover how a set of user stories solve a customer problem. End users may be involved in the collaborative process as well, most probably giving inputs in the user journey and the sequence of activities – which makes it an elicitation technique. Sequencing activities may be an output of previously performed elicitation, resulting from analysis of that information. Lastly, acceptance criteria may be included in the details of the story mapping, which forces the team to start stepping up into the requirements validation. In the case of users not have been part of collaborative process, the model may be used to validate together with users that the user journey is indeed correct.

Complexity Science Terminology Applied to Business Requirements

Borrowing from the terminology used in the complexity science field, in which systems are classified as Simple, Complicated or Complex, this article provides a short description of these characteristics, and suggests using the same terms, in a different interpretation, in the context of documenting Business Requirements.

In the book “Getting to Maybe: How the World Is Changed: Westley, Frances, Zimmerman, Brenda, Patton, Michael” the following meaning is given to the three types of systems:

<<Simple>> systems are based on a small set of rules or steps to function. They are robust, in the sense that the same input will generate the same output, with little variance. An example would be baking a cake by following a recipe.

<<Complicated>> system have a high number of rules and laws, even thousands, like the project to launch a spaceship to reach the Space Station. These systems can be managed by computers, are considered predictable, but they are not necessarily robust: an error in an input parameter can lead to a different outcome than desired (the spaceship ending up on another place instead of the Space Station).

<<Complex>> systems are those in which the component agents interact amongst themselves and adapt to the new conditions. For example, raising a teenager is complex because teenagers change their moods, they interact with their peers and the environment, and they adapt to the new context. Such systems are emergent, and other examples include languages, a pandemic spread, or the car traffic.

 

We can adapt this complexity systems terminology to the situation of a Business Analyst who is part of an on-going project to enhance an ERP application (Enterprise Resource Planning) in a specific organization.

In this framework the starting point are the business users who face the real world and have <<Complex>> problems. The role of the Business Analyst is to translate that complexity into a form that is <<Complicated>> but fully described. The final form of this translation is the Business Requirements Document, aligning the understanding of the requirements among the team members, with sections detailing <<Simple>> logical components.

 

From this perspective regarding the Business Analysts’ work, the categories are:

<<Complex>> problems known by the business users. These problems may touch several areas of the ERP, have unclear or vague rules, or the granularity of the logic and desired actions is not fully explained.

<<Complicated>> requirements with a high number of rules, parameters, procedures, algorithms. With the huge computing power available nowadays, ERP applications are able to handle such complicated systems, and they routinely process huge number of transactions run very fast on large databases.

 

Advertisement

 

Using the complexity lens to look at requirements provides benefits such as:

First, this perspective can reduce the frustration within the project team around requirements, by emphasizing the complex and changing nature of the business user’s problems.

Second, it increases the appreciation for the Business Analysts’ role in the team, since their talent and ability to translate <<Complex>> problems into <<Complicated>> requirements are key in this framework.

Lastly, untangling complex problems requires judgment, intuition, and context sensing – all characteristics that are unique to the human mind. In the current environment dominated by Artificial Intelligence applications, a Business Analyst with this view in mind would have less to worry about a being replaced by a robot and losing their job, if they see themselves from the position of contributing to the translation of complex problems into complicated requirements.

 

Equipped with the tools and techniques recommended by the BABOK, Business Analysts are in a unique position in the process of documenting the business requirements.

The following components of a Business Analyst’s toolkit are particularly useful in the requirements elicitation and documentation described in this framework:

  • Offering mock-ups and diagrams: Visual representations of the requirements can be highly effective in helping stakeholders understand the proposed solution.
  • Setting up test cases in the ERP application, to assess how well the information currently provided by the ERP system can support the proposed changes.
  • Performing a gap analysis between current and future state. This technique helps ensure that the requirements align with the overall business objectives and can serve as a basis for defining the scope and priorities of the project.
  • Organizing walkthrough sessions to gather feedback and ensure that the requirements are accurately captured. Business Analysts can generate and present iterations of the BRD with revision points, and address follow-up questions from stakeholders.
  • Asking open-ended questions to encourage stakeholders to share their insights, perspectives, and concerns, which can help uncover hidden requirements and potential issues that may not be captured through closed-ended questions.
  • Nudging the discussion towards “what” is the ultimate need, instead of the “how” to meet that need. This approach encourages stakeholders to articulate their true requirements and avoid premature solutioning. This approach allows for more creativity and flexibility in exploring different options and arriving at the most appropriate solution.
  • Being flexible in case the requirements change in time as the project progresses. and appreciate that the scenarios might be unchartered territory for the users themselves.

Best of BATimes: Six Effective Elicitation Questions to Ask Your Stakeholders

Asking questions during interviews or as part of a structured requirements workshop is commonplace. However, the most important question is one you should be asking yourself:

Am I asking the RIGHT questions?

Here are a few of my favorite elicitation questions and what they might reveal about your project.

 

1. What are the biggest challenges in your role?

A key part of any BAs role is to understand the context of the project: where does this project “sit” within the larger organization.
Having stakeholders describe the challenges in their role prompts both leaders and doers to share information that moves “outside the box” of the project.

Especially in an interview setting, this question allows the collection of “stories” that will elaborate and cement the value of the project and its required capabilities. These “stories” are concrete examples of the business need that will communicate the value of the project to sponsors, vendors, testers, developers, etc. throughout the project lifecycle.

Though you want to be cautious to avoid scope creep, briefly stepping outside the confines of the project can also help you identify:

  • Organizational risks
  • Missing stakeholders
  • Requirement gaps

 

2. What does success look like?

As I noted in my May article, “The Top 5 Mistakes in Requirements Practices and Documentation”, many project teams spend too much time focusing on the as-is current state.

Asking stakeholders to define success is a perfect way to move workshop or brainstorming discussions from the current state into the future state.

In the initial stages of elicitation, this question will help gather a clear overview of what capabilities are required for the project. The output of this question to can be used to create high-level conceptual models of the future state.

This question can also be used in beginning to elicit requirements for very specific features and capabilities. The challenge will be keeping stakeholders focused on the “what”: users, processes, rules, events and data. The discussion migrating to technology, systems and solution may risk that the true needs go undiscovered.

Perhaps most importantly, focusing on success frames the discussion in a positive light, emphasizes benefits, and gets stakeholders excited about the value the project will provide to their organization.

 

3. Who do you think is impacted (positive and negative) by the project and how?

We have all seen that even small projects can create a ripple effect that touches many parts of an organization. All of the people touched by the project’s ripples are potential stakeholders. Identifying and categorizing the roles of various stakeholders is key to successful elicitation.

In the initial phases of business analysis, understanding who is affected by the project will help you refine the scope of the solution and build your core team of stakeholders.

Asking this question throughout the project lifecycle will also help you:

  • Identify new stakeholders
  • Identify and mitigate risks/constraints
  • Redefine needs or identify new needs
  • Elaborate requirements
  • Prioritize requirements

 

Advertisement

 

4. What would happen if we don’t change the way things are done today?

Use this question as an alternative to: “Why are we doing this project?” or “Why is this project important?”

As you may know, I love the question “Why?” but I hate to use it. “Why” questions tend to put people in a defensive position and can inhibit open and honest communication.

Also, framing the discussion in terms of “no changes”, is essentially asking stakeholders to define the current state. However, this phrasing will limit the “as-is” discussion to the processes and events that need to change.

Stakeholders will help you understand the key opportunities, risks of dormancy, the benefits of change — all-important inputs for successful elicitation.

 

5. What other changes are happening within the organization that may impact this project?

Most organizations function in a state of constant change. To avoid being blindsided, find stakeholders that understand how new strategies, policies, regulations, processes, and technology, might impact our projects.

Many project teams tend to isolate themselves within the silo of their business unit—often in an effort to stay focused. However, too much isolation can lead to missed opportunities for:

  • Collaboration
  • Integration
  • Sharing of best practices

Keeping attuned to organizational changes can help to:

  • Mitigate risks
  • Estimate project deliverable dates
  • Manage scope
  • Identify constraints
  • Understand interdependencies

 

6. How would you describe the process?

This is really a technique, with multiple questions, that I use frequently with SMEs in one-on-one interviews or in small groups. This technique is most effective when delving into the details of specific processes or events. Here’s what I do:

  1. I ask the SME/s to describe the process for me.
  2. Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
  3. As they explain the process I ask, “What parts of the process would you improve and why?”
  4. I also ask, “What ideas do you and your teammates talk about as ways to improve the process?”

At the end of this exercise, I leave the room with a validated visual of the current state of the process and a list of opportunities to add value to the organization.

Let me know if these questions will help you or share your favorite elicitation questions below.