Comments on Better Projects: Business Analysis Life Cycles

I was impressed by a reference to "trawling for re...

2008-11-10T17:26:57.702+11:00

I was impressed by a reference to "trawling for requirements" in a book recently. The idea is that we start with a wide mesh net, and get the big ones (and stuff we don't want, of course, which we have to throw back), and then progressively use finer mesh nets.

This works in with agile theory, since it allows for some work up front, but then progressive just-in-time realisation as we move through the project.

Reactions?

This suggests the 'lifecycle' may be repeated many times during a project. Does that turn this into more of a list of activities, rather than a sequence?

Two reasons;a) Your BA needs to be around at the e...

2008-06-10T20:41:16.057+10:00

Two reasons;

a) Your BA needs to be around at the end or else there is no accountability for quality of work.

b) Your BA needs to be there at least at UAT to assist with interpretation, clarification and the development of workarounds. Their domain knwlegde at this time makes them highly useful.

I guess if you have a team of 15 BAs not all of them need to be there, but the senior BAs who have an end to end view of the product should be.

In your experience, is this an unusual practice?

Why do you think the BA has to be involved through...

2008-06-10T13:58:06.321+10:00

Why do you think the BA has to be involved through implementation 'to be effective'? I can see the BA being available as needed, but with limited resources being the norm, I usually move on to do more requirements work on a new project, and then to the next one... such that a number of projects that I did requirements for may be going on at the same time.

Thanks Maria.It is an intersting subject.David - W...

2008-06-09T10:56:10.018+10:00

Thanks Maria.

It is an intersting subject.

David - What do you think about including design and development in the lifecycle?

My thoughts are that to be really effective in the role the BA needs to follow the requirements right through to implementation/release.

Anyone else got comments?

Thanks Craig, your thoughts are very helpful. My m...

2008-06-09T08:29:12.523+10:00

Thanks Craig, your thoughts are very helpful.

My main issue with IIBA model is that its requirements focus doesn't address the design and iterative nature of the process. Will check Jonathon's Boehm model as well and build upon the feedback I'm getting and post soon about my next stage in the thought process.

Maria

Craig - My thoughts.. Interesting topic/undertakin...

2008-06-08T12:18:44.233+10:00

Craig -
My thoughts.. Interesting topic/undertaking. I can't cite the original source for this, but what you're describing also sounds similar to the requirements lifecycle that includes the following steps:

- Eliciation
- 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. The "management" piece, though, would include the obvious storage of requirements and change management, but also iterative loops back into the earlier phases as needed.

I've also seen this broken out as a smaller "spiral within a spiral" if you're familiar with Boehm's Spiral Model for development.

Now, I know that is referring to the "requirements" lifecycle and not specifically to the "business analysis" lifecycle, which would also include the enterprise analysis part, but one could question whether or not the enterprise analysis part couldn't be slid into the arena(s) of elicitation and/or analysis.

This new model includes design and development, wh...

2008-06-06T23:46:33.517+10:00

This new model includes design and development, which makes it a full systems development life-cycle, not just a Business Analysis model. That is what popped out at me, anyway...