6 June 2008

Business Analysis Life Cycles

Maria at BA Rocks has (is) put (ing) together a Business Analysis lifecycle model for her employer (a client) and has come up with the following 6 stages.

1. Initiation and Scoping
2. Research and Analysis
3. Requirements Specification
4. Design
5. Development and Implementation
6. Evaluation and Conclusion

This list doesn’t sufficiently represent Maria’s ideas. You can read her post on this topic here.

One of her objectives is to build a model that is able to accommodate the dynamic and iterative nature of many of today’s projects. To adequately represent this I have presented this list diagrammatically.

(Maria, what do you think? Am I on the right track?)

Now, the model raises a number of questions. The first is why raise a new model when the IIBA’s model is there for the using?

Or, as an Australian BA, she could turn to the AABA’s framework. What is it that’s missing so that a new model needs to be constructed?

Rather than write another 500 words on the topic I’d rather hear what you have to say.

  • Do the industry frameworks provide sufficient guidance to you?
  • How do you customise your work to fit the client?
  • Do you have your own model?


  1. 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...

  2. Anonymous12:18 pm

    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.

  3. 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.


  4. 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?

  5. 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.

  6. 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?

  7. 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.


    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?