I guess I am finding more and more that my work as a BA is being utilised over the life of the project (rather than just up front at the requirements gathering stage). Its not so much expanding the BA role as utilising business analysis skills across all the life cycle stages of development.

Still forming my ideas so the feedback is very valuable.

Mia

your comments are much appreciated
Will check out the model you suggest as I’m finding the main issue with IIBA model is that its requirements focus doesn’t address the design and iterative nature of the process. Have checked Craig’s blog and this is helpful as well so will l and build upon the feedback I’m getting and post soon about my next stage in the thought process.

Maria

I made a similar comment over on Craig’s blog as well, but wanted to share my two cents here in case you might find it useful in some small way.

Anyway, I can’t cite the original source for this - I first heard it in a training course - but the “business analysis life cycle” you’re describing also sounds similar to the “requirements life cycle” I’ve come across a number of times that includes the following steps:

- Elicitation
- Analysis
- Specification
- Validation
- Management

If you do a search on those items as a string, you’ll find all sorts of stuff. I won’t describe each phase as the names are pretty much self-evident.

I will note that where you mention “design”, “development and implementation”, “evaluation and conclusion”, the model I mentioned basically includes all of those under “requirements management.” The idea there being the tasks of the BA really don’t vary that much based on whether the project is in analysis, design, code, or test. (That said, in some organizations BA’s do design and testing as well as requirements, so I suppose it’s all relative.)

I’ve also seen this requirements piece represented in spiral form. It’s sort of like a smaller spiral within the larger spiral of the Boehm’s Spiral Model for development, if you’re familiar with it. (I know a picture or two would be helpful here. I may throw something up on my blog in the next few days if I can come up with it.)

The nifty thing with this model is that it can be applied to classic waterfall SDLC’s, where you make one or two lengthy trips around the spiral (in “big requirements up front fashion), or it can accommodate a model where you cycle through the spiral many times in quick iterations as is becoming more prevalent.

Now, you could say that the “enterprise analysis” part of the BA role, as mentioned in the BABOK, is not adequately covered in the requirements life cycle cited above. That said, I don’t know that enterprise analysis would really roll up cleanly under a “life cycle” model. Maybe it would. If so, it just hasn’t hit me yet.

Enterprise analysis can wander more into the strategic and not so much the tactical or project-based stuff that BA’s are currently more known for. That said, to make the model work, you could also just include enterprise analysis in your elicitation and analysis phases.

Alright, I’m getting to be way longer-winded than I intended, here. I’ll be following your progress on this undertaking, though. Let me know if I can be of help.

Is that what you are trying to do? Increase the scope? And if so, to what advantage or improvement?

I am intersted in your idea. I have extended your list a little further at my blog.

I’d like to extend this further via the blogs if you are interested.

Craig