Tag: Requirements

Building a House: Analogy for the Business Analysis Role

Two years ago, my friend asked me what my job role was, and I said that I was a business analyst in Information Technology (IT). However, after all this time, she still doesn’t understand what my job entails. To assist friends of other business analysts around the world, I have written this article to explain what we do. I can’t wait until she reads my article!

 

Let us propose a world where business analysts are architects, the developers are builders, the inspector is the quality assurance team, and our software client would like to build a house.

Usually, the builders would start building the lounge. This sounds good because they are off to a flying start and the walls are going up, but the builders do not know how many bedrooms the house will need, where the best location for the bedrooms is, or even why they are building the building at all. The kitchen might even end up with four sinks and no oven, or the kitchen might not even exist. Finding out that this is not what the customer wanted when the house is half built is expensive to fix, will not meet the deadline, and worst of all, the house will not be what the customer wants at all!

A far better idea is to include an architect on the team.

 

Firstly, the architect will sit with the customer and find out the high-level goals of the building, for example, the customer would like a family house in a quiet suburb because currently they live in a noisy complex. They are also expecting a second child. The business analyst (BA) is gathering context on the problem and the customer’s vision.

Right from the start the architect explains the process that will be followed, builds a trusting relationship with the customer, and starts to manage the expectations of the customer, for example, steering the customer away from a water slide in the lounge which could take an extra six weeks. This is change management, which should happen as early as possible and should set the tone for the rest of the project. It should also be noted that the business analyst is the ambassador of user needs and so is the team member that focuses on them.

The architect will then dive into the details and obtain the customer’s requirements, draw diagrams, and can even print a 3D model of the house. It will become clear to the architect and the customer exactly where the main bedroom will be, how large it is, how many windows it will have and so much more. This is the Business Analyst (BA) conducting requirement elicitation, drawing up wireframes, and prototyping the solution. The BA will also choose the best way to engage with the customer, such as through prototyping in workshops or sticky notes on a virtual whiteboard.

 

Advertisement

 

To double-check that the architect and the customer are on the same page, the architect will draw up some basic design criteria that the building must meet, for the example given that the room is the older child’s room, when the builders are building the walls, then they must build two windows. This is writing acceptance criteria.

A very important step is that the architect will confirm their findings with the customer to make sure everything is covered and covered correctly. This is the validation and sign-off stage. Note that architects can suggest solutions to fill in the gaps, for example, they can suggest that the house should face north, but it is ultimately it is the customer who makes the decision.

 

Our builders are brilliant in their field, but they are better at building than communicating. This means that the BA needs to translate what the customer needs so that they fully understand what to do. BAs bridge the gap between the business and technical sides. The architect explains “what” needs to be done, the builders decide “how” it will be done, for example, the builders will use wheelbarrows.

The architect will sit with an interior designer and discuss the finer details to make the house as well designed as possible, for example how to place the cupboards in the kitchen to make the layout practical. This represents the interaction of the BA with the user experience experts to make sure the software is intuitive and a positive experience.

 

Now the builders know what to do, the building continues nicely, with a few hiccups along the way such as the bricks weren’t delivered on time. The architect will work closely with the builders every day and if the builders have any questions or are unclear on anything then the architect needs to go back to the customer for answers.

Each day the entire team, with the customer, will stand on the pavement and have a quick meeting to let the other team members know what they did yesterday, what they are doing today, and if there are any blockers or dependency issues. This is a daily standup meeting.

 

Every second week, the team sit around a table on Friday afternoon with some drinks and discuss how the project is going. They say what has worked well and what could have gone better. They decide what to keep doing and what new ways can be put in place to improve the way they are doing their work. This is a retrospective meeting used with an agile approach.

Once a section of the building is complete, then the architect will walk around the building with the building inspector. The inspector will check every detail to ensure the house is built to code and is safe while the architect will ensure that the building is what the customer actually wanted. Sometimes the builders can get really enthusiastic, go off course, and place a central fountain in the kitchen and forget the sink. This is a verification process step.

The house is completed, with a few bumps along the way, but the customer is thrilled (hopefully) and can’t wait to move in.

 

In conclusion, call us business analysts, business architects, solution designers, or craftsmen but understand that we undertake many daily tasks and play a vital role in the development of successful software projects. We may not build the building but direct it (builders like to build theme parks) and save the customer a lot of money. Hopefully, my friend will understand what I do now!

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.

 

Best of BATimes: The 7 Habits of Highly Effective BAs

In my experience as a Business Analyst (BA), I have seen many analysts struggle in trying to strike the right levels of analysis. Some analysts tend to overanalyze while others, under analyze. Getting trapped in the dilemma of when to stop and/or when to continue analyzing can put you into a vicious cycle of ineffectiveness and devaluation. The result: zero business outcome yet a ton of frustration and a huge load of wasted time and effort.

The 7 habits of highly effective BAs guide you in establishing thresholds and protocols for your analysis finish line and helps you determine how far you are from the finish line. These 7 habits provide you with a compass that guides you to determine when to hit the breaks and/or when to accelerate your analysis.

 

1. Be cognizant of the allotted project budget and schedules. Create a mini work breakdown structure (WBS) for yourself that distributes analysis tasks and activities based on the allotted time and effort. Over time, you won’t need to formally put this down on paper and your mind will automatically signal you when you’ve exceeded or unfulfilled the allotments. However, be aware that this strategy alone may not help you in striking the perfect level of analysis. For best results, combine this technique with one or more strategies described below. For example, requirements analysis can be about 25-30% of an overall development project. If the analysis is taking more time than testing and programming put together, there is something evidently wrong. The flaw with this approach is that you will need to continuously monitor your project spend before you determine you’re on the wrong track which sometimes can be too late in the game to backtrack.

2. Establish and communicate success criteria at the onset to understand where the real finish line is. Once you have fulfilled the success criterion, you’ll know that you’ve more or less completed the required level of analysis.

3. When performing use case analysis, ensure you’ve considered not only normal and alternate flows but also exception flows. In my experience, at least 1 normal flow, 2-3 alternate flows, and 0-1 exception flows are typically enough.

 

Advertisement

 

4. Ensure you understand the inputs (preconditions), outputs (outcomes and postconditions), and actors before you start your analysis. This will help you say focused and on the right track in terms of scope.

5. Always refer back to the business objectives, goals, and vision. When performing any sub-activity, always ask yourself if what you are doing is related to, impacts or is impacted by the overarching goals. If the answer is no, stop! If the answer is yes, continue and go back to the success criterion.

6. Define limitations, assumptions, and constraints and keep those in mind all along when performing analysis. This will help you rule out some scenarios and help you continue on your journey to a fruitful analytical activity.

7. Know your audience. Ask yourself these questions: Who is the receiver of my analysis? Who would my work interest? Knowing who you are performing the analysis for will help you identify the level of detail required and therefore the amount of analysis to perform.