Those performing Business Analysis are typically known as Business Analysts (BAs) and often work in dynamic environments where change is not only anticipated, but is expected and embraced. I was recently asked to look at developing a Business Analysis Life Cycle to help frame an approach to BA work. I started with the broad definition of Business Analysis - as a vehicle to generate and present unambiguous information to help facilitate the decision making process and deliver business outcomes and stressed that the and involves a portfolio of techniques that focus on demonstrating an understanding of the client’s needs and identifying how best to meet those needs.
I believe Business Analysis is increasingly encompassing broader organisational challenges (e.g. strategic planning and business health checks) and solutions to business problems, which may include systems, processes, organisational change or a combination of these. Whetehr you are a Systems BA, Process BA or Finacial BA, the discipline of Busienss Analsysis is a core caspability. As a consultant this core capability, Business Analysis, is achieved through developing effective relationships with the business and technology Subject Matter Experts (SMEs), extracting, analysing and presenting relevant information to ensure key stakeholders have a common expectation of the quality, scope, cost and benefits of the preferred solution. It very much about facilitation and communication of requirements to meet needs of stakeholders.
To develop the Business Analysis Life Cycle (BALC) I reviewed the framework of the key BA professional bodies:
· IIBA - International Institute of Business Analysis
· ABAA – Australian Business Analysis Association
and found that the key concepts of any BA life cycle are:
· Establish and define the purpose of business analysis;
· Establish and define the core activities an BA may be required to undertake in achieving the business purpose; and
· Establish and define the key facilitating processes and resources that will support an BA in achieving analysis objectives.
It is important that the BALC reflects the iterative facilitation and co-ordination processes undertaken in dynamic environments and therefore the following skills/governance actions of Communication, Planning and Control are central to the approach and support the core elements/activities of the BA role and reflects the analytical process from initiation/definition through to conclusion. I see these six phases as:
1. Initiation and Scoping
2. Research and Analysis
3. Requirements Specification
4. Design
5. Development and Implementation
6. Evaluation and Conclusion
Maria
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
I am not sure where you are going with this… what you have here is an overall project life-cycle. With design and development included, this is more than the generally accepted scope of business analysis, or the Business Analyst.
Is that what you are trying to do? Increase the scope? And if so, to what advantage or improvement?
Hi there, 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.
Thanks Jonathon,
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
Thanks David for your comments as well,
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
…another place to look for ideas is the product lifecycle…