So, it’s been a month now. That’s enough of a break, right?

Here’s my (very early) thoughts about what version 3.0 might look like. A big consideration for me will be that it shouldn’t be too much longer than 2.0. I can see adding a chapter on lifecycles and methodologies to explicitly show how the BABOK maps against them, for instance, and other materials that might bulk it up a bit, but I’d be very reluctant to see it go over 300 pages. So that means that it would stay at about the current level of depth and detail on the topics it covers.

First, the obvious–whenever it comes out, we will run surveys to see if there are any important changes in which techniques are generally accepted (either more so or less so).

Then, there may be some restructuring of tasks. Nothing like the 1.6-2.0 transition, to be sure, but I think there’s some opportunity to structure things a little more consistently and also a couple of things that might deserve to be tasks in their own right.

However, I think the biggest changes will come from various efforts now underway. We’re doing analysis on BA competency models, and version 3.0 will emphasize those qualities that we find are most important to being effective as a BA. We expect to see work done to align the BABOK more closely with other critical standards. And thirdly, the field itself will change, as we see how Agile methods, BPM, outsourcing, and other current hot trends play out over the next few years. (My personal guess is that at least one or two of those will peak this year or next, but we’ll see).

As always, though, we’re open to feedback. Let me know! And in the meantime, I have plenty to keep me busy.

Kevin Brennan, CBAP
VP, Professional Development

I should mention that my job around here has changed too. As you might have noticed in the posts below, I’ve been signing off with a new title.

We’ve merged the Body of Knowledge and Professional Development groups into a single group. I am now heading up the new Professional Development team as the VP of Professional Development, and I’m now responsible for the development of IIBA standards (yes, plural) the EEP program, our webinars, and developing other educational opportunities and resources for our members.

I’d like to thank Cherifa Liamani, our former VP of Professional Development, who will be staying on as part of the PD team. I’ll be working a lot with Julian in his new role as well.

And finally…version 2.0 is now complete. We have a little production work left (such as verifying the list of contributors, creating the table of contents, and similar) but the main body is done and has been sent to the IIBA Board of Directors for approval. Again, thank you to everyone who contributed, participated in reviews, commented on it, or who has contributed to shaping ideas around the profession of business analysis over the last few years. We’ve been working on this for four-and-a-half years, and I am both happy and strangely sad to see it go. Sure, there will be other revisions and other standards, but my life just won’t be the same without people asking me “when is the BABOK coming out?”

Kevin Brennan, CBAP
VP, Professional Development

Yes, I know.

As I found when we put version 1.6 out the door, there are issues with version 2 that we just won’t have time to fix, or which it’s too late to fix (because the impact it would have on other work underway is bigger than the benefit of the change). Looking back on my life in IT, this is a feeling I have every time I release something.

Yesterday I spent a little time pulling together a proposed outline for BABOK version 3. I won’t post it up here because it’s too early to be talking in public about this stuff. We might very well find after version 2 rolls out that these aren’t the right changes to make in any case, based on the feedback we get.

With version 2 the BABOK shrunk from 60-odd tasks to 32. I think we can actually reduce that a little further, and I also think there may be one or two tasks that should be added. In addition, there’s some tasks that should move between KAs.

Don’t get me wrong, the changes I’ve identified so far are a lot smaller than the changes from 1.6 to 2. I could describe them all in a blog post, unlike the 1.6 changes which will take a 15-page document to address at even a high level. With the exception of a new task or two, these changes wouldn’t affect the scope of the BABOK at all. They’re mostly about reorganizing things a little to deal with some persistent issues we’re encountering or misconceptions that are affecting people’s ability to understand what the BABOK actually says.

Finally, yes, we are getting very close to being able to announce the release date.

Kevin Brennan, CBAP
VP, Body of Knowledge

So last night, as I lay in bed trying to get to sleep, I was thinking about the BABOK. Yes, that’s sad. Anyway, what I was thinking about in particular is the tendency of people to look at it as describing a process. I fear the only way to dislodge that thinking is to replace the model with a different one familiar to BAs.

I think it would be a closer approximation of our intent if readers looked at the BABOK as the set of use cases that constitute business analysis. Like use cases, they have goals, pre-conditions (the inputs) and post-conditions (the outputs). Also like use cases, but unlike processes, there are no rules telling you when to perform tasks in the BABOK, when to loop back to previously executed tasks, and so forth.

Activities in a process flow are strongly connected. An activity cannot begin until its predecessor is complete, and if it runs into difficulties then the process must specify how to handle that. A use case, on the other hand, has no real connection to other use cases (leaving «include» and «extend» aside for a moment). It can be performed whenever its preconditions are met. If there’s a problem with one of the inputs, there’s no specified process one follows to fix it.

There are, of course, key differences. The BABOK doesn’t tell you how to perform tasks, just what the task is. The model is not at all perfect. It’s just a better model than thinking of the BABOK as a process.

Another way to look at it is functional decomposition. As you read this, please keep in mind that this is an extremely informal description of the BABOK. Don’t try to parse these words too closely.

At the top level we have the subject matter, which is business analysis. Informally, business analysis is about analyzing how organizations function in order to help stakeholders understand how to accomplish organizational goals and objectives. We can break that down into two major subtopics. One is the analysis part. The other is the dealing with stakeholders part.

On the analysis side, we break it down into three KAs. That itself breaks down into three KAs: one for defining the problem, one for defining solutions to that problem, and one for making sure that when a solution is delivered it actually solves the problem.

On the stakeholder side, we also have three KAs. One involves getting information we need for analysis, one involves providing analyzed information to people who need it, and the third focuses on organizing the work we need to accomplish to perform all the other KAs.

Each KA is then broken down further into 4-7 tasks that detail what is required to do those things in the context that business analysts operate in. That context, by the way, is what makes business analysis distinct from other roles in its “family” like Product Management, IAs, Usability Professionals, and so forth. At the very high level I described above, you could apply the same structure to all of them, but each would perform somewhat different tasks and use different techniques to define the problem, validate the solution, and so forth.

Finally, there’s the Underlying Competencies, which describe the soft skills and general knowledge that helps you do all the things above more effectively.

I could write about how techniques fit into this but this post is already long enough.

Kevin Brennan, CBAP
VP, Body of Knowledge

Once again, a big thank you to all who participated. We received over 1,100 responses to the survey. On the whole, I believe that respondents were generally more experienced and had a wider range of exposure to different methodologies than the industry norm, which means the results are very likely to align with actual industry practice. We did not find major differences in the results based on experience with different methodologies.

In analyzing the survey, we combined some techniques into a single description where they are used for essentially the same purpose in business analysis. Some changes were made to the list as well based on our assessment of the value of a given technique. I also excluded some techniques from this list that only support a single task in the BABOK, as they will be described in the text of those tasks (for example, requirements prioritization techniques). More detail on the process and on the categorization of Primary and Secondary techniques can be found here.

Finally, I can assure you that the BABOK will include a strong disclaimer to make it clear that the IIBA does not intend or desire that this listing be viewed as a recommendation on our part as to the value of a given technique. We’re not saying that this is what you should be doing; we’re saying that this is what most BAs are doing and so if you know these things you’ll be prepared to work in most organizations.

Minor changes to this list in the final cut of v2 are still possible, but it will look very much like this.

Primary

Primary techniques are ones that over 80% of BAs use occasionally or regularly.

• Brainstorming
• Business Metrics and KPIs
• Business Rules
• Data Dictionaries and Glossaries
• Data Flow Diagrams
• Data Models (ERD, Class Diagram)
• Interviews
• Issue and Defect Tracking
• Non-functional Requirements Analysis
• Organizational Models
• Process Models (includes Flowcharts and Activity Diagrams)
• Requirements Workshops
• Scenarios, Use Cases, and User Stories

Secondary

These are used regularly or occasionally by more than 50% but less than 80% of BAs.

• Acceptance Criteria
• Architectural and Compliance Frameworks
• Benchmarking
• Document Analysis
• Environmental Analysis (includes Market, Industry, Competitive)
• Estimation Techniques (for Solution Scope as distinct from BA tasks which are covered in the BAP&M KA)
• Event and State Model
• Focus Groups
• Functional Decomposition (includes Work and Product Breakdown Structures)
• Gap Analysis
• Impact Analysis
• Interface Analysis
• Lessons Learned and Retrospectives
• Observation
• Prototyping
• Requirements Risk Analysis
• Root Cause Analysis
• Scoping Diagrams (Context Diagram, Use Case Diagram)
• Sequence Diagrams
• Storyboards/Screen Flows
• Structured Walkthrough/Inspection
• Survey/Questionnaire
• SWOT Analysis

Kevin Brennan, CBAP
VP, Body of Knowledge