I picked up the habit of skipping introductions in college. Most often college-edition novels and philosophical works, of which I read plenty, contained the editor’s reaction to the text. It never made sense to me to read this before I had even read the book itself!
So it’s no surprise that I’ve bypassed a good deep reading of the preface and introduction to the BABOK until preparing for the exam. What a mistake I had made! There’s some good stuff in there! Here are a few of my favorite passages:
IIBA encourages all practitioners of business analysis to be open to new approaches and new ideas, and wishes to encourage innovation in the practice of business analysis (2) .
Sometimes the BABOK can feel like a self-contained world in which everything we do as business analysts must have a spot. But when you begin to look at the content with this perspective, it’s more about a framework for bringing new ideas into the profession. I still think that we BAs have a lot to learn from UX professionals (and vice versa). And when you read the list of sources of information that follows the introduction, you get the feeling that business analysis is more about inclusion and trying new approaches, than following a rigid methodology or process. Nice. This is my kind of BA.
The BABOK Guide contains a description of generally accepted practices in the field of business analysis. …. In addition, practices which are not generally accepted by the business analysis community at the time of publication may be equally effective, than the practices described in the BABOK Guide (3).
As Kym Byron, my instructor for BA Mentor’s Exam Prep Class, so nicely noted, this is what separates the BABOK from other BA texts. It’s not one person’s opinion on how to do BA. It’s not an example of a methodology that has worked in a certain set of circumstances. It represents a collection of tasks and techniques that have been validated by a large number of business analysis professionals in their active work.
As such, the BABOK is an “as is” document, not a “to be” or, definitely a “should be.” Although many take it that way and look to the BABOK as a methodology. This is an important constraint to keep in mind when we consider the value of certification against the knowledge in the BABOK as well as consider how we use the BABOK in our work. Assimilating the BABOK is more about becoming connected with business analysis as it’s done today, flaws and all. For individuals or organizations looking for a baseline to measure themselves against, the BABOK would provide that framework. For organizations and individuals looking to become best in class, this might mean leveraging the BABOK framework but looking beyond it for practices and approaches. At least that’s how I understand the implications of this passage.
Finally, my absolute favorite.
Similarly, we do not assume that requirements are analyzed at any particular level of detail, other than to say that they should be assessed to whatever level of depth is necessary for understanding and action (5).
Get out the yellow highlighters and pink stickers! Or, you might be re-reading the above sentence and wondering what the heck I’m so excited about. Well, I feel like a bit of my own BA Manifesto is validated (even if it’s publication does post-date the publication of the BABOK 2.0) with the focus here on understanding (what I called alignment) and action (what I called positive change).
I also feel validated in the natural tension I feel on so many projects where I try to balance clarity and ambiguity and decide when “enough is enough.” Here’s our professional body of literature telling us that this tension is justified, because our work is not just to document the requirements, but to assess the requirements at the right level of detail to keep the project moving and ensure everyone understands the implications of those requirements.
Hmm…perhaps I should re-evaluate my “skip the introduction” philosophy. I wonder what else I’m missing?
>>Learn More About Becoming a CBAP or CCBA
Interested in becoming a CBAP or CCBA? We cover 8 steps to the CBAP certification, that will take you to just learning about the certification to successfully sitting for the exam.
Hi Laura,
Inspired by you, I have also submitted my application on August 15th (I have been holding it for over a 1 month) and now waiting for my results…..keep going.. you motivate me….Congratulations and Good Luck..
thanks.
My favorite from the intro is actually the definition of business analysis itself. How many times have I had this conversation:
“What do you do?”
“I’m a business analyst.”
(Pause, while I wait to see if they know what that is… No, of course they don’t.)
“Business analysis is…”
Actually, I rarely quote the BABOK because I would sound very strange, but I do make more chatty version: “I generally work in the realm between IT and business, helping all the stakeholders understand the organizations goals in order to create systems that support those goals.” Note that I say generally, although I’m finding myself move out of IT and into enterprise analysis and dealing with business systems and communcation, rather than IT systems specifically.
Anyway, I found the structure for my elevator speech in Section 1.2.
Laura, I was smiling too ’cause being a fellow Philosophy major, and generally a circular type systems thinker, I intuitively read texts by jumping around. hey, linearity is overrated! Other than fiction of course where a linear storyline kind of matters, I personally learn better by moving around and filling in pieces slowly to form a more and more complex mental map of the work. Maybe that’s an even more radical approach than just skipping the intro, but i’m with you in spirt.
I’m totally with you when you said “we BAs have a lot to learn from UX professionals (and vice versa)”. I have a UX friend in New York, and we enjoy talking (or is it sparring) over the criss-crossing overlapping roles of our fields. Patrick Quattlebaum’s point about getting involved early in the process, and applying design (Big D) thinking at that level to the “Business” itself, and to the business “strategy” is where our two fields meet up and innovate together.
Without using the word itself, what I believe your careful read of the BABOK intro is saying is, “go forth, and innovate!”. In other words be creative. And isn’t that more fun?
Hi Curtis,
Yes, perhaps I learned this in philosophy too…40-50 page introductions of blubber..blah!
While I think the BABOK supports reading my jumping around, I can see that all the pieces aren’t going to fall into place until I complete my deep dive of all sections. So there’s a bit of needing to jump around, dig back through, explore further, think big picture, etc….that’s all part of assimilating the framework that’s there and making sense of it for me, so that this isn’t just an exercise purely in memorization, but also in learning.
Yes, the UX stuff is fun and relevant! Someday I’ll be able to invest some more attention to that and hopefully bring the most relevant pieces to business analysts!
Hi Laura,
Glad to hear you like it! Yes, you’re right, the Introduction in the BABOK Guide is definitely not just fluff. It’s intended to tell people what the book is for and how it’s intended to be used. I’m glad you spotted those passages because they’re really important.
One thing I actually wanted to include, but that we didn’t manage to pull together in time, was a discussion of different types of projects and which techniques might be best used in them. I’m a little torn over whether that would have done more harm than good though–on the one hand it might have helped people realize that they don’t need to do everything on every project, but on the other hand they might not take the time to consider whether to try something not on the list.
In a broad sense, I’m happy to tell BAs, especially those consulting BAs who may work in a number of different companies and industries, that it’s probably a good idea to be familiar with every technique in the BABOK Guide. I have never, for instance, used a DFD, but enough people do that I may need to be able to understand one. However, if you’re a business process analyst, you might be fine with a small set of techniques that you’d need to know really well.
As far as the Agile Extension goes, we ran into a bit of a dilemma in that other than User Stories there are very few specifically agile analysis tools that could be called “generally accepted” to the same extent that the tools in the core BABOK Guide can. So, we decided to go with the judgement of the team members and include tools which we agreed either needed revision/expansion from the content in the core BABOK Guide or additional techniques that the original didn’t cover. Most of the content of the extension is techniques. It’ll be out early in September as a draft for feedback. This is not going to be the final version–we need feedback from the community, and the team identified a number of areas we need to address in future iterations.
Hi Kevin,
Thanks for stopping by to share your views and especially this idea of including a list of different types of projects with techniques in the BABOK. My initial reaction was that this would be nearly impossible to create as each project has so many factors that such a guide would either become exceedingly complex or, as you note, incomplete and therefore used inappropriately. But if anyone can distill this monster, my guess is that it would be you! 🙂
My second thought on this is that it’s really not just the techniques, but how we choose to do the tasks. For example, in my CBAP Exam Prep course we were talking about the Business Analysis Approach and what it means to include the “deliverables”…the consensus was that it could be a template, an example, or instructions…it would all depend on the context of your project and what organizational process assets you have in place. So the BABOK doesn’t prescribe the “how”, it just tell us the “what” and in this case it means that defining the BA approach means we give appropriate direction as to the deliverables to be created (amongst other aspects of the approach).
Perhaps some examples for each task and technique, purely for illustrative reasons, would be a useful addition to future BABOK versions, with enough attention to diversity that the examples cannot be misinterpreted as the only way to realize a specific task.
Regarding the Agile Extension, that will be interesting. I feel like part of the problem there is that agile adoption is so diverse in and of itself. Although I’ve worked in agile-“ish” environments, I’m not sure my experience would count or be valid in the context of sharing feedback as to what techniques I found relevant. I often found myself relying on traditional analysis techniques and using them outside the context of the project and then bringing everything back within the agile structure on an as-needed basis to support the project lifecycle. From conversations with other BAs, this seems common and I can see why this would create a dilemma for writing such an Extension.
Laura,
Yeah…in fact that approach is perfectly valid within the context of the Agile Extension. Most of the existing techniques are still perfectly usable in agile. But you’ll be able to judge for yourself in a few weeks.
Good to know! Part of what I was also trying to say was that even outside of analysis the “agile” environments I worked in were not purely agile. For example, in one case the development team worked in sprints but did not do reviews and we did not have defined product ownership. Don’t want to fret those details here except to say that how much adoption constitutes “agile” for the purposes of providing meaningful feedback on the extension would be a good line to draw in the sand.
Laura, nice post. I find that so many people get fixated on “doing what [they think] the book says” and do not get that it is a framework. Some of this is caused by training companies/courses that focus on covering every element of the BABOK as a checklist. I think of it as a list of POSSIBLE best practices – IF they fit your project.
The BABOK should be compatible with agile for example. However I find that many folks say well it says “blah” in this section… and that is not agile. The BABOK does not say how to do everything on your project! Interpreting every section in some mid-evil way with a goal generating a pile of useless trash is not the point! Of course with an agile extension of the BABOK http://community.theiiba.org/profile.htm?mode=pvb&pid=17&op=ViewArticle&articleId=386&blogId=1, this should help – let’s hope MoSCoW does not make the final cut or is clarified REALLY well – hate to have people abuse that concept yet again!
The level of detail snippet is a great one – BAs often focus on attempting to get to perfection instead of what is good enough to achieve the value they need!
Anyway – nice post – people should approach the BABOK as a toolbox, not one tool. Open the box, choose what you think are the tools to achieve success (I guess I need to get back to you on that pencil discussion!). Throwing the entire toolbox at the problem is not going to help!
Thanks so much Jake! Yes, I have seen at least one presentation using the list of techniques as a checklist and a measurement tool for BA performance. That kind of information does seem to further this misconception!
Within the text itself, I am finding there are a few “musts” and “shoulds” that could support the perception that the BABOK is not consistent with agile. But these are typically followed by caveats where you can see how you’d make it work in an agile environment. There is definitely a danger in referring to any individual piece out of context which does make it valuable as a framework but difficult as a reference tool. I find myself wondering how I will continue to keep this all straight in my head once the exam is done!
I think you are going to make me smile every week :). You have a talent for capturing exactly what some of us feel and think but have not yet expressed. We should add this validation to our list of benefits for becoming a CBAP. It’s great to know that we are not alone in our thinking and conclusions!
Making people smile by writing about the BABOK. Who would have ever thought that was in the cards for me? 🙂
It is great to know that we are not alone and from the comments on other posts in this series I think many BAs do feel this way in assimilating the information that’s in the BABOK. But I think first you have to open up your mind to it, which is not always easy the first or second read through. One of the peers I meet with every couple weeks who is also pursuing his CBAP on a similar timeline really struggled with the introduction as it didn’t seem to represent to him how he did his work. Perhaps the pressure of the exam creates the opening that allows the information in? That’s sort of what I’m feeling now.