Review By: Cathy Bell
08/01/2011Howard Podeswa boils down the scope of the business analyst (BA) role to "an important liaison between business stakeholders and the technical team (software developers, vendors, etc.)." As liaisons, we ought to understand both the business and technology worlds and keep up with the best practices of both. However, the amount of information available to us can be overwhelming, and that can make it hard to quickly find something to fill our current needs.

The Business Analyst's Handbook creates a concise reference for a BA based on A Guide to the Business Analysis Body of Knowledge, the Information Technology Infrastructure Library, and the Unified Modeling Language. It emphasizes the role of the BA for each phase of the project lifecycle.

Readers can easily find a tool for a project by reviewing the table of contents. Lists, checklists, and tables keep the information organized and will make this book a very useful reference tool. This is not a book that most readers will read cover to cover. Instead, they will read the material that is pertinent to their current tasks.

Chapter 2, "Meeting Guide," outlines who should attend your meetings, based on the type of meeting you are facilitating—a kickoff meeting, a risk-analysis meeting, or a meeting to gather detailed requirements. A table explains each participant's responsibility in the meeting, when particular types of meetings should be held, what documents should be prepared in advance of the meeting, and what the meeting artifacts should be. A BA armed with this guideline should be able to put an end to meetings that lack purpose, to unprepared participants, and to a lack of documentation when meetings are over.

Chapter 4, "BA Toolkit," gives detailed explanations of the tools available for the BA, with a table that shows where in the lifecycle to use these tools. The tools it covers include activity diagrams, data-flow diagrams, Pareto analysis, requirements-traceability matrices, and state diagrams. If you are unsure about these types of tools, this chapter explains how they are relevant to different project types and where they are useful in the project flow.

Chapter 6 contains the various templates that a BA will need during a project, including the business requirements document, business and system use cases, a risk-analysis template, and a test-script template. The author gives useful lists and templates, but I wish he had included them on a website or disc. It’s not that I’m lazy; I just see typing a document from a book as an avoidable task.

The author created this book based on job aides that his company distributes to its clients. While it is geared toward an incremental, iterative approach, the material is easily adaptable to other methodologies. This book would be very useful as a reference tool for a BA with experience, and the glossary of business analysis terms would help a junior BA understand unfamiliar terms.