Feb 22, 2012 2
I have to start out by confessing that The Business Analyst’s Handbook, by Howard Podeswa, might not have been the Business Analysis book for me. Software business analysis, like project management, is practiced in two ways these days: the documentation-heavy style necessitated by large organizations where hundreds of people touch a project, versus the looser style used by smaller, nimbler organizations. I mostly practice the latter, and as such, this book proposes a lot of BA deliverables that I’d never incorporate into my work.
That said, there’s much of use here, even if you’re doing analysis on a document-just-in-time Agile team. Podeswa and the colleagues on whose experience he draws know their trade, and while this book isn’t exactly fun subway reading, it does what it says on the tin. It’s an exhaustive catalog of BA best practices, suggesting whom you should consult at every stage of requirements gathering, whom you should invite to meetings, and what should go into the resulting documentation.
If you’re looking for a conversational introduction to the BA’s trade, run like hell from this book. If you’re looking for a desk reference that you can flip open when you’ve got that nagging feeling you might have missed someone or something when setting up a work session, you might find it useful.
I say “might” only because of my main gripe with this book: awful organization. The information is useful, but ugly and hard to access. I can get useful but ugly off of the web (where at least I have the “Find” command to see me through). A book ought to be better designed. The fault probably lies with the book’s publishers, Course Technology. Specifically, much of the information in the book is presented in tables. This would be fine, if the tables were laid out in spreads together with the explanatory text so that you could easily tell what subject a given table covered, and cross reference between table and text. It would have cost them more page count to do this, as it would’ve created quite a bit of white space. Instead, it looks like someone just dumped a Word doc into inDesign with minimal flow control. For a $50 cover price, it’s fair to expect better layout.
Finally, although I may have given the impression above that I’m allergic to documentation-heavy analysis processes, what I’m really averse to is producing a document when it’s not needed. If you want a complete playbook of all the types of documents that might be useful, this book is great. It’s opened my eyes to some documents that I wouldn’t have thought to add to my process before, and given me names for some things that I was already doing on my own but didn’t realize there were standard terms for (like swimlanes). And if you love UML, you’ll be happy to see that many of the Handbook’s recommended deliverables are UML documents.
Overall a handy book, although I strongly recommend looking at a preview before you buy to see if the aforementioned layout problems drive you to distraction. Amazon’s discounted price ($28 at time of this writing) also works in the book’s favor.