Jonathan Babcock

Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you’re new here, you may want to subscribe to my RSS feed. If you’d prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!Wikipedia (with help from Ivar Jacobson) defines actors as:

[S]omething or [...]

As I was skimming the book Agile Project Management—How to Succeed in the Face of Changing Project Requirements by Gary Chin, I came across a method I liked for determining whether to use classic or agile management methods.

According to Chin, the determination is made by evaluating project environments and organizational stakeholders.

Not long ago, CIO.com ran an article entitled, Why Business Analysts Are So Important for IT and CIOs. The article has apparently piqued the interest of many business analysts as I’ve seen it mentioned in various blogs and discussion groups.

It is exciting that reliable research firms like Forrester are producing reports such as this that acknowledge the value of the BA role and provide such a positive outlook.

I wanted, first, to point out the article to those of you who may not yet have read it; second, to share some of my own commentary on passages that I found particularly interesting. So, here we go:

I’ve long been of the opinion that involving as many stakeholders in the project as early as possible is a key to successful business analysis, and, more importantly, to successful projects, and have said as much in a few of my posts on this site.

Jim Highsmith, in the book Agile project management : creating innovative products, thinks that the reason projects tend to have so much documentation and so few results is that:

In my business analysis group, we identify user requirements through use cases, but we don’t use user stories. As I am not extremely well-versed when it comes to some of the agile methods, I thought I’d do some research to learn more about user stores and to determine how user stories are different from use cases and from traditional requirements.

Here are some links to interesting articles and information I’ve found during the past week.
If you’ve ever doubted the need for requirements elicitation for an ERP project, you need to read this. Apparently a company is suing an ERP software vendor because the software it was expecting to work in a promised date did not [...]

Here are some interesting items I’ve come across over the past week or so that I’d like to share.
I read a though-provoking article the other day by Tony Lock on why IT is still not communicating well with its business counterparts. Per Lock:

[F]ew organisations have formally established and monitored service levels reporting in terminology and [...]