Tag: Business Analysis

As a Business Analyst (BA) how often have you been asked to provide an estimate for a requirements elicitation and analysis effort and, upon providing it, had your estimate cut back by management in a seemingly arbitrary fashion?

I recently attended a conference for Project Managers (PMs) and BAs where this issue was brought up during a requirements planning techniques seminar. I heard stories from several of the BAs in attendance that their management would look at the estimated time and resource plans and summarily cut them by 30% while keeping the same project scope. Other managers would simply say, “that’s too much time, figure out how to do it faster.” The question raised in the seminar was “how do you deal with these situations or prevent them from happening?”

The best approach I have found is to be armed with as much objective and quantifiable information as possible to support your estimate – in other words – a detailed Work Breakdown Structure (WBS).

When developing estimates for requirements elicitation and analysis, many PMs and BAs will lay out the tasks to be executed and even include some resource assignments and dependencies, in a high-level WBS. More often than not, however, they are not very detailed and, subsequently, not very accurate. Below is an example of a basic WBS and Level of Effort estimate for a seemingly simple project involving elicitation of requirements for a system, assuming the project requires interviews with 2 groups of users and an analysis of associated existing process and system documentation.

Although the estimate seems to include all the necessary tasks, durations and dependencies, if we look at it through the lens of a Business Analyst who might be responsible for doing the actual work, we will see that the effort required becomes significantly larger.

When we factor in standard information gathering, interview preparation, requirements analysis, review and revision tasks along with their associated time frames, we see that our simple requirements analysis effort takes significantly longer than initially planned to complete. The development of this more comprehensive listing of tasks is based on a variety of inputs including:

• Analyst’s experience on past projects and associated activities
• Similar project comparisons
• Exhaustive brainstorming and analysis of all tasks required to complete the deliverables

Having a detailed WBS allows the BA to call out all the activities required and helps ensure all project members are aware of required time and resources.

Related Article: The Agile BA – Moving Beyond the Backlog

That said, just because a BA can show why they require certain requests, a certain timeline, and set of resources to complete the analysis effort, does not guarantee that those requests will be granted. There may be existing time, resource or budget constraints with which the project and requirements analysis effort must comply. In those instances, a detailed WBS can be used to evaluate objectively which activities and scope items are essential and which can possibly be omitted. This will hopefully result in an adjustment of scope, schedule or deliverable expectations.

Example: If I can only have two (2) days it means I can only get requirements from one (1) of the two groups.

If adjustments to expectations are not made, at least this exercise should result in a specific identification of risks to the requirements effort so that steps can be taken to mitigate the probability or impact of their occurrence.

Example: If I can only have three (3) days it means I can’t do a thorough document analysis, so the interviewees need to make sure they cover all possible processes and requirements.

By developing a detailed WBS for any analysis effort, a BA can help ensure that deliverable expectations are understood and agreed to by all project participants and that adequate time and resources are available to complete the process effectively.

BABOK Notes

The process of estimating tasks and durations for requirements elicitation described above are covered in detail in the Business Analysis Planning section of the Business Analysis Body of Knowledge (BABOK) published by the International Institute of Business Analysis (IIBA). A link to the BABOK on the IIBA website is provided below:
http://www.iiba.org/babok-guide.aspx

In 1961, the great Julia Child revolutionized the cooking industry with her book “Mastering the Art of French Cooking”. This book cemented Julia as an expert in French cuisine and launched her career as a gourmet chef.

In 1963, Julia used her new found fame to revolutionize the television industry by creating a weekly half-hour cooking program. Her success paved the way for all of the cooking shows on television today.

So what does this brief history of Julia Child have to do with Business Analysis you may ask? Let me explain. Julia’s book was extremely successful because it provided very clear, simple instructions along with supporting photographs to illustrate the final product. This recipe for success launched Julia Child’s career from relative obscurity to international fame.

To succeed as a Business Analyst, you must strive to deliver consistently clear and unambiguous requirements that are understood by all audiences. The most successful business analysts will also create visuals to support the requirements they write. In this respect, BAs would be very wise to follow the formula that launched the success of Julia’s famous book.

I’ve developed a recipe that business analysts can follow that will ensure they will deliver high-quality requirements that are guaranteed to satisfy the business needs of their customers. The recipe is as follows:

1. Define the problem 
2. Define the Scope
3. Create an Actor – Goal list
4. Create supporting visuals
5. Write detailed requirements 

Step 1 – Define the Problem

The very first step in the business analysis process is to define accurately the problem the business needs to solve. It is human nature to rush into a solution. However, a great BA would be wise to keep in mind the famous words of Albert Einstein, who once said “If I had one hour to save the world I would spend 55 minutes defining the problem and 5 minutes solving it.”

Related Article: Know Your Audience – Don’t Let Requirements Get Lost in Translation

In my experience, most people on the project team as well as management, are impatient and want to push forward with implementing a solution as quickly as possible. They fall in love with the solution, not the problem. This mentality significantly increases the risk that the project will deliver a solution that does not fully meet the customers’ expectations. BAs must lead teams to fall in love with the problem, not the solution. So how does a BA slow the team down and concentrate on defining the problem? We need to use a simple template for a well-defined problem statement. The template contains four simple sections.

Ideal – this section allows our customers to define the ideal solution or process. It forces the stakeholders and the project team to define what would be an ideal solution to their problem. The information discovered via this exercise will help determine the actual scope of the project as well as uncover the most important features the customers are expecting. Feel free to use collaborative games or other interesting elicitation techniques to make this a fun exercise for your team.

Reality – this section allows our customers to define the current reality of their situation. Understanding the reality of a customer’s current situation is helpful to understand the most significant pain points in the current process. Empathy mapping is a useful technique for this section since it allows you to understand how users feel and think about the current process.

Consequences – this section is used to define the actual consequences the business may suffer if the problem is not solved. It is critical to define the actual consequences that the current problem is causing. For example, ask your stakeholders if the current problem is causing productivity loss, revenue loss, or is putting the company at a competitive disadvantage. Understanding the actual consequences allows the business to prioritize the project. It also allows the project team to understand how the solution they create will actually impact the business.

Proposal – the proposal section is used to articulate options for solving the problem. Completing this section allows the delivery team the opportunity to provide an initial set of solution options which are feasible. Having your customers and the delivery team have a discussion on potential solution options is extremely important. It ensures both sides are in agreement on the path forward and helps to define further the scope of the project.

Step 2 – Define the Scope

Once the problem is defined via a well-defined Problem Statement the scope of the solution is much easier to lock down. The Scope Statement does not need to be a complicated document that takes a long time to complete. The information provided in the problem statement should allow you to come quickly to an agreement on what is in scope as well as what is out of scope.

Step 3 – Create an Actor – Goal List

Great business analysts are able to understand who is involved in the current process as well as who will be involved in using the new solution. This analysis results in the creation of a list of Actors associated with the current problem. For each Actor identified the business analyst should understand the goal they are trying to achieve. For example, let’s consider a typical web-based application that allows a customer to order products. A realistic Actor – Goal list for this solution would be:

Customer – Search for Product

Customer – View a Specific Item

Customer – Add Item to Basket

Customer – Place Order System – Verify Payment Information

Obviously, this is not a complete list, but you should get the idea. If you write each goal in Verb – Noun format you may simply associate each Actor – Goal combination with a single Use Case or User Story. This exercise allows you to organize the requirements in a way that ensures the most important functions of the stakeholders are accounted for.

Step 4 – Create Supporting Visuals

Using visualization is absolutely critical to convey requirements. Visuals allow for the proper discussion to occur in order to elicit the detailed requirements from your stakeholders. A picture truly is worth a thousand words. Visuals may include mock wireframes, prototypes, process flows, and data flow diagrams. Visually mocking up the solution allows the BA to obtain feedback quickly and discuss the details of the proposed solution prior to developing it. Taking the time to create visuals and discuss them allows the detailed requirements to fall simply out of the discussion. You will be amazed at how easily the requirements become clear when you are discussing a visual with your stakeholders.

Step 5 – Write Detailed Requirements

Once the problem has been well-defined and agreed upon, the scope has been solidified, the actors and their goals have been considered, and the visuals have been discussed, you are ready to put together the detailed requirements. Each requirement should be associated to a single Use Case or User Story, which is directly associated to a single Actor – Goal. This ensures that each requirement is directly involved in satisfying a goal of your customer and will be adding value to the solution. Requirements should be written in Subject-Verb-Object (SVO) format and be clear and unambiguous. The key to clarity in the English language is the relationship between the Subject, Verb, and Object. If a common sentence clearly defines WHO the Subject is, WHAT they will be doing and to whom they are doing it, then the reader should have no problem understanding it.

Following this recipe for requirements elicitation may not launch you into international fame and a lucrative television show. However, it is likely to set you on a path for success in your business analysis career by establishing agreement and trust within the team.