Skip to content


The importance of stakeholder input and elicitation.

Lee, Morgan

In some organizations, a Business Analyst (BA) will sit down with a project sponsor and collect their requirements.  The BA will go back to their cubicle and write a fantastic Business Requirements Document (BRD). The BA will review the document with the sponsor, get approval and sign-off, and hand the document over to the developers.

What is wrong with you might ask? Sometimes nothing, sometimes a lot.

The project sponsor may think they know exactly what they want and how to do it. From my experience, this has been a rare situation. By not consulting with other stakeholders in the initial requirements phase, you may experience many problems down the road. Developers often have a different way to handle a feature implementation, testers may know a better way to test, users may or may not want certain features included or omitted, but you will never know unless you ask or spend the money to develop the product and find out the hard (and expensive) way that things should have been done differently.

A BA should not just gather requirements. They should elicit requirements. This means drawing out the real requirements rather than just documenting what one person may think they want. Elicitation should include as many people as possible in the time and resources given. Discussion with the developers, testers, and end users (people that use the product) can often help shape requirements.  It is important to get the right stakeholder information as early in the process as possible.  Why develop a product that the client does not want?

Posted in Business Analyst, Requirements, Techniques.

Tagged with , , .


Tracking Project Phase Information

Custom lists are a great way to keep track of what I am working on and they can help keep me motivated.

Here is a sample template for Tracking Project Phase Information. This template includes information such as
Project Name; Phase name or number, Description, Deliverable, Deliver dates, Benefits, Risks, Issues, Updates, and Changes for the next phase or future release.

The template contains two samples that can be easily customized to capture project phase information.

Tracking Project Phase Information (166)

Posted in Template.

Tagged with .


Adding presentations to your BA toolkit

Lee, MorganProjects can be improved with better communication techniques.
As a business analyst, I have had to present on a number of topics including:
Business and User Requirements;
Software Evaluations;
New process ideas;
Recommendations; and
Templates and documents; etc.

A presentation is another tool to add to your BA toolkit. One technique I like to use is to treat my presentation like a project. This can include a planning, analysis, development, testing, and delivery phase.

1. Planning – Define your presentation objectives. Asking questions can help.
What is the purpose of the presentation, Is it to discover, brainstorm, sell, inform, or persuade the stakeholder?  What do you want the stakeholders to do as a result of the presentation, Do you want them to learn, acknowledge, or perform an action item?
What do you want to say and how do you want to deliver it?  How long will it take, Who should I invite, and should I use a white board or video presentation?

2. Analysis – Understand your topic, get to know your audience and find a way to connect the two.  Try and find out who will be attending.  Are the stakeholders technical or Management people?  Do they understand the details or just want high level information?  How will they use this information?  Try and find out what the stakeholders are expecting to hear, learn, discuss, or avoid?

3. Development – Design a presentation that matches your stakeholders. You may need to prepare different presentations based on different stakeholder groups. Determine when you will ask questions or engage the audience. Pick a presentation format that is appropriate for the stakeholders and environment you are in. Open with a story or fact that will get their attention. Describe what the presentation is about, Consider adding an executive summary at the beginning and then discuss the information to backup your findings. At the end, recap the information and assign an action item. Give the stakeholders a purpose for them being there.

4. Testing – Practice your presentation as much as you can in an environment as close to the real thing. Try and use the same equipment and props that you will use during the presentation. Create a list of questions that you think the stakeholders might ask and say the answers out loud to see if it sounds good. You can record yourself and play it back to help identify your strengths and weaknesses.

5. Delivery – Be prepared. Take your time and try to interact with the audience. Maintain good eye contact.  Answer questions when you know the answer and offer to find out when you don’t or find someone that will (ask the audience if they know the answer). Try and read the body language of the audience to see if your topic is keeping them engaged. “Switch things up”. Get feedback after the presentation and use that feedback to help you improve on the next project (presentation).

There are many ways to present and some techniques are more effective than others.
Plan your presentation, Analyze who be attending, Develop the presentation based on your audience, Test the presentation much as you can, and use your BA skills to deliver the best presentation you can.

Try different techniques and find what works best for you. Good luck.

Posted in 5 Things, Article, Business Analyst, Questions, Tools.

Tagged with .


Fit / Gap Analysis

Morgan T. LeeA Fit / Gap analysis is a great tool to help identify the strengths and weaknesses in a current or future state environment.  A Fit / Gap can be used to analyze software, processes, knowledge, skills, activities, et cetera.

I often use a Fit / Gap process to compare the business and user requirements with the features which clients are looking for.  There are many ways to perform a Fit / Gap, but one of the techniques I like to use is to assign a priority to see how well a feature fits a desired requirement:

High – Out of the box or with minor setup
Medium – Requires a small amount of work to satisfy the requirement
Low – Requires a lot of work to satisfy the requirement (Often custom configuration is required)
None – Requirement is not satisfied
N/A – Does not apply

If a requirement is not met (None or N/A) this may be considered a gap.
When you have a gap in requirements, you should do your best to identify a possible solution or workaround.
Gaps can often be met with plug-ins, software configuration, coding, or additional third party hardware / software.

Steps I follow to complete the Fit /Gap process:

  •  Work with stakeholders to identify requirements (get client to approve list);
  •  Identify list of potential solutions to help satisfy requirements;
  •  Narrow down list with clients help to create a short list (2-5 solutions);
  •  Perform a Fit / Gap analysis on short list;
  •  Prioritize and score fit based on approved requirements;
  •  Compile results (Metrics and diagrams);
  •  Create Fit / Gap analysis report;
  •  Include an executive summary with recommendations;
  •  Include detailed findings with diagrams to back up recommendations; and
  •  Present findings to client (get client approval).

 

Sample Fit / Gap Matrix

Requirement Solution 1 Solution 2 Solution 3 Solution 4 Solution 5
Req #1 High High High Medium High
Req #2 High Low High Medium Low
Req #3 Medium None High None Low
Req #4 N/A N/A N/A N/A N/A
Req #5 High Medium Low None N/A

Posted in Article, Business Analyst, Techniques.

Tagged with , .