Paul Mulvey

In the business analysis profession, there is no one-size-fits-all solution. As you develop your project type, you need to know all the tools available to you; think through all the variables related to the people, project characteristics, and the process; and then determine what tasks you need to complete. Data warehouse projects A data warehouse is a solution that brings together information from diverse sources and puts it in a format that stakeholders can easily access when making complex business decisions.

The data flow diagram is a helpful diagram for business analysts that shows the parties and systems involved with a particular process, as well as the data and interfaces involved when dealing with external agents (those parties or systems that exchange information with the project but over which your project has no control).

In prototyping, you create a model of the proposed solution. In business analysis, a prototype, or mockup, generally means a representation of a computer screen and examples of how the user will interact with the application to accomplish a task to solve the business problem. The business analyst creates the prototype, usually with help from the technical team.

Verification is what most people think of when they hear the word testing — it’s the process of testing whether a business analysis solution does what it’s designed to do. During verification, the testing team (which may consist of developers, quality assurance [QA] people, and some business analysts [BAs]) put the software through its paces to both confirm that it operates as expected and ensure that it conforms to the design specifications laid out earlier in the project.

Understanding and analyzing the risks of a business analysis project is an important part of identifying and documenting the project scope. Risks can be project-related and/or business-related: Project risks: Project risks are potential problems that may impede the completion of a project. They include situations like losing a key person prior to the completion of the project or having a team inexperienced with a commercial off-the-shelf tool (or COTS tool, a pre-packaged, one-size-fits-all solution that may or may not have the ability for customization).

After the business has decided a problem is worth pursuing in its analysis, you should create a problem statement. A problem statement is the conglomeration of four key elements into one expression to convey the issue at hand: Root cause problem Impacted stakeholders/product users Impacts of the issues Effects a successful solution must include The problem statement is a critical component of a project’s statement of purpose or charter.

A solution (or product) position statement is a description and positioning of a specific solution approach in a business analysis. It generally follows the format of “For the target audience of U who need V, the new product W is a solution that will do X. Unlike alternative Y, our solution does Z.” An important element of a good solution is that it solves a real problem worth solving and ultimately provides value back to the audience using the solution.

Aside from fulfilling a business analyst (BA) role at a company, you may have the opportunity apply your various business analysis skills to other roles. You can parse out individual business analysis skills to make yourself more marketable, take advantage of opportunities, and meet a company’s specific needs for growth and improvement.

When verifying and validating solutions, you perform a requirements review, a structured audit in which you give participants the opportunity to ask questions and make suggestions in order to improve the quality of the product being reviewed. Keeping the requirements review session moving forward is the facilitator’s job; because you may be wearing that hat during the meeting, here are some tips for conducting the requirements review session: Put on a thick skin when documents you authored are being reviewed.