• The release date is sometime in 2012, which has always more or less been the plan. As we get closer to that time we will communicate other information. As with 2.0, you can expect a 4-6 month period between the 3.0 release and updates to the exams.
• I expect it to be a significant upgrade, with some new tasks and possible reorganization of KAs, but not nearly as big as the 1.6 – 2.0 change. Most tasks will be the same, techniques will still be in their own section, and so forth.
• Don’t ask about volunteering yet. The call for participants in the core team will be published in BA Connection when we’re ready to kick off.

So, what’s changing? Well, one of the things I’ve spent time on to date is the definition of business analysis. In version 2.0, the definition is:

Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.

I felt that there was room for improvement in this definition. It’s wordy, it’s a little complex, and it includes things that aren’t strictly accurate. For instance:

• It says that “BAs work as a liaison among stakeholders”. But do we always? I worked on one project where something like 90% of my analysis work was interpreting a government-defined standard for data transmission and figuring how a software application should translate that into billing information. I wasn’t really liaising anything. Also, as you move up the enterprise, there’s less liaising and more researching and recommending. The liaison role is important, certainly, and many BAs focus a lot on it. But it’s not necessary…because you can do business analysis without it.
• “understand the structure, policies and operations”…what about strategy? What about IT? I can (and we do) claim these are implicit, but the risk of any list like this is that you may find that you’ve left something out.
• “enable an organization to achieve its goals”. Two problems here. One is that it implies that everything a BA does must fit with the overall organizational strategy. That’s not wrong as such, but it may not always be practical. Does every single requirement really tie back to an organizational objective? Plus I have another objection–organizations don’t have goals. People have goals. The leadership of the organization may have goals, but the organization itself can’t.

The key to any good definition is that it should include everything that is necessary and nothing that is not. In other words, everything in the BABOK® Guide should in some way be traceable back to that definition, and we should also strip out anything that is “aspirational”. That means removing anything that talks about what a BA “should” do or know unless it can be proven to be necessary. It should also be applicable to everything from maintenance or continuous improvement to enterprise-level work.To see the kind of things we’re looking at, check out the Competency Model (pages 6-7) which gives a glimpse of the roles that the definition should encompass.

Also, I intentionally avoided using words like “facilitate” or “support”. There were quite a few “support” tasks in version 1.6 and we removed every last one of them from 2.0, either by narrowing the scope of the task or by redefining the nature of the work. When you get into “support” in a professional body of knowledge, you’re actually crossing the line into another profession that is actually responsible for the outcome in question. For instance, as a business analyst (job title) the project manager, developer, or tester may ask me to help them out by doing something. That’s fine, and as a team member I should help other people–but in that case I’m assisting you in performing your role, not doing business analysis. As a business analysis professional, if something is an outcome of business analysis I and only I am accountable and responsible for it.

(In practice, this is not always true. Many business analysts are too junior to have final accountability for the ultimate analysis product, which may rest with more senior analysts or even managers. However, we’re talking about business analysis here, not your job or mine, and the BABOK should encompass everything needed to reach that final result).

So, after a lot of effort, I came up with the following (not final) definition.

Business analysis defines the capabilities that enable an organization to create value for its stakeholders.

There’s still validation to do before this becomes final, but I think it captures the essence of the profession. Comments are, of course, welcome.

In particular, I’m thinking of some of the note-taking and brainstorming applications. They hove the ability to allow you to take notes in a session, capture associated diagrams, record audio, and so on…but most of them are aimed at students and so don’t feel quite right. There are no tools to help develop visions or business cases, track the status of a requirement or feature, and so forth, even though it wouldn’t take that much to add some basic support for those. If I had the time I might do it myself.

A colleague received a recent inquiry asking for guidelines on how to estimate the relative value contribution of various IT functions, such as business analysis, database administration, and IT security. This is roughly like trying to quantify the relative value contributions of a car’s engine and its transmission. The outcome delivered by the car—transportation in a certain style—absolutely depends on both. You can calculate the cost as the sum of individual contributions, but you can’t calculate the value that way…

This is one reason successful IT organizations reframe the conversation. They report to the rest of the business in terms of services and the outcomes those services create, as opposed to the IT components that contribute to those services.

I’d definitely recommend this book to business analysts, as it also attacks other widely held myths like “‘The business’ is IT’s customer”. There’s a reason that the BABOK Guide defines customers as external to the organization—because viewing the rest of the organization as your customer divorces you of responsibility for the success of your organization’s strategy. It creates an internal focus that is detrimental to overall performance.

That said, even if you can’t quantify the benefits you can certainly quantify the costs of poor performance, and when it comes to business analysis they’re immense. I will have more to say about this later but studies suggest that poor requirements are responsible for an average of 20% of the cost of a typical project. When you aggregate that across overall IT spending worldwide, it’s equal to the cost of the Apollo program, annually.

Their other key insight for business analysts is that you should focus on showing that you can deliver value for money before trying to take a role in setting organizational strategy. For a lot of business analysts, there’s a real focus on getting involved in business cases and defining projects at initiation. I absolutely agree that companies should be looking to their BAs to do that, but what Hunter and Westerman argue in this book is that that’s not likely to happen unless you can first demonstrate your ability to deliver high-quality, useful, and valid requirements.

Anyway, last night I was thinking about the relative importance of various learning and improvement methods to people at the various levels, and how much those things will affect how effective a person is. I think it looks something like this:

That is to say, at the Novice level you are almost entirely dependent on some kind of training or education to help you figure out what to do (I’m including mentoring in that). As you progress through the Advanced Beginner and Competent stages, your own experience becomes more important until it becomes the primary predictor of effectiveness.

Finally, though, experimentation with new ideas starts to become a factor. Most of the people I know who are really good at whatever they do try new approaches just because. Self-education seems to be more important than training at those levels of performance, although formal training doesn’t stop being useful. I’m not sure if that’s a limitation of training itself or a reflection of the reality that there are rarely enough practitioners seeking training at the expert level to create the market demand (or for that matter enough trainers).

This model also has interesting implications for certification programs. Many of those programs aren’t very clear about what level of competency they actually are certifying. For example, I see a lot of discussion/dispute in the Agile community over the Scrum Alliance certification program, which is based on a course lasting a few days. Is that a legitimate approach? It can be, if you are aiming at the Novice or Advanced Beginner level. However, if people think that they’re getting Competent or Proficient practitioners out of a course they’re going to be disappointed. At the other end of the scale, I’m not clear on whether it’s practical to try and certify Expert practitioners.

I’m going to be spending more time investigating the practical implications of the Dreyfus Model. The reason I’m thinking about that, of course, is that it has real implications for professional development at different stages of a person’s career. The mechanisms that are good at one level won’t work at others.

BA Insight will serve as a place to talk “unofficially” about business analysis and other topics of interest to me. Over the last couple of years I’ve felt a certain pressure to make sure my posts on IIBA were in keeping with my official role. Some people seem to get uncomfortable when the guy responsible for the BABOK Guide expresses a firm opinion about things that disagrees with theirs. Most times, that stems from a concern that their views will be dismissed by IIBA. I’ve had a lot of practice separating my personal views from my work for IIBA, though. Nevertheless, I think it’s best that I express those views on a “personal” channel.

I’ve pulled in many of my old posts from the IIBA SLT Blog, deleting those that were pure status updates or the like. Official IIBA stuff will continue to be blogged about on the IIBA Community Network, and of course some things will be cross-posted.

This site will also serve as a home for my business. Yes, I work for IIBA but it’s as a contractor, not an employee, and it’s not my sole source of income. I don’t do work that would conflict with my IIBA responsibilities, but I am available for other short-term consulting engagements or for side projects that can be done part-time. Drop me a line if you want to know more.

Other than that, I look forward to getting back into the stream of blogging again.

I’ve realized for a while now that I needed to get my own site up and running again, but it’s something that tends to have to get done in my spare time. If you’ve stumbled across this, it means you got here before I finished getting it built.

Business Analysis, on the other hand, has appeared on the stage only recently and the efforts being directed towards distilling a body of knowledge, and associated certification standards and educational programs, seem very much pre-mature.

I hear this claim a lot–that business analysis is a “new” profession. I don’t think it’s as new as a lot of people seem to think, though. What’s changed is that a) there’s a growing recognition of the need for the role and b) a lot of people who always did business analysis are starting to identify as BAs and using that title instead of the many different titles that prevailed in the past.

Business analysis has been around long enough for me to spend my entire career doing it. In fact, it was pretty much my first job out of school, and I certainly wasn’t the first BA to work in the companies that hired me. It’s been around long enough that my mother has experience in the role. She’s been retired for years, and finds the BABOK Guide both fully understandable and can see how it relates to what she used to do. If I look back to my first BA job, I believe my colleagues and I would have then understood what the BABOK Guide was driving at and how it related to what we did. Certainly, new techniques and approaches have been introduced over time, and we did our best to ensure that current practice and innovations were properly addressed in version 2.0. But frankly, given that my mother can understand perfectly well what I do and how these techniques work despite having retired from IT a decade ago, I don’t think that business analysis is as unstable as Mr. Gollner thinks it is.

The comparison to project management is an interesting one–largely because Mr. Gollner seems to be talking about PMI and project management as it is today without considering how it got there. One of the major reasons that “project management” is considered to be a well-defined role today is precisely because PMI built and developed a body of knowledge that became the standard for our understanding of the role. PMI didn’t emerge from a well-defined, universally accepted standard understanding of project management–it helped to create it.

The other issue that’s behind a lot of the criticisms in this article rests with the distinction between “generally accepted practices” and “best practices”. Mr. Gollner complains:

As an example, consider the issue of analytical modeling notations, where the Business Analysis Body of Knowledge (BABOK) is forced to catalogue a ramshackle list of options with many of these, such as Entity-Relationship Diagrams (ERD) or the “Unified” Modeling Language (UML), being deeply rooted in very specific implementation paradigms for information technology.

His complaint seems to be that the practice of requirements analysis is still quite immature, given that there are still a lot of different modeling practices in use, many of which overlap or are designed specifically for IT, and we don’t definitively understand which techniques are most effective.

All that is true, but I don’t think it’s relevant, unless you believe that if we can’t do it perfectly we shouldn’t do it at all.

The BABOK Guide describes “generally accepted practice”–that is, what business analysts are actually doing. In fact, we’ve done enough research, surveys, solicitation of expert opinion, and collection of feedback from practitioners to be quite confident that the BABOK Guide really does accurately describe that. It gives us a standard of practice for BAs–if I walk into a new job as a BA, knowing how to do what the BABOK describes, I can reasonably expect to be prepared for most of the situations I will encounter on the job. Similarly, an employer who hires a BA has a basis for understanding what they can expect that BA to know how to do. For many BA practitioners, this has been a major improvement over what exists today.

That shared set of expectations is a necessary first step to figuring out what best practices are. Again, to go back to the example of PMI, the PMBOK Guide only talked about “generally accepted practice” for the first 20 years or so–PMI has only very recently reached the stage where they believe they can identify best practices (and I know that there are those who still strongly disagree with them). Until you have a shared set of expectations and outcomes a role or profession is supposed to achieve, how can you say that one approach is better than another? How can you say what those tools and techniques he wants us to be developing are supposed to be used for?

From my perspective, Mr. Gollner has got things almost exactly backwards. He’s complaining that IIBA shouldn’t be doing what we’re doing until the profession is where project management is today, but project management got there because PMI, along with many other individuals and organizations, laid the groundwork by doing what IIBA is doing now.

Would I like to be in a position to tell the world that a certain set of business analysis practices can be proven to reliably and consistently produce significant returns for organizations that practice them? Of course I would! As long as IIBA is being compared to PMI, though, let’s not forget that PMI only produced a study showing that for project management last year–40 years after the organization was founded, 24 years after the PMP certification was launched, and 14 years after the first complete draft of the PMBOK was published (and yes, the PMP does predate the PMBOK).

Now, I don’t want to wait until 2023 to demonstrate the value of business analysis. My hope, in fact, is that we will be in a position to do that within the next few years and even have some of that research incorporated into the next edition of the BABOK Guide. However, that research would be impossible without the shared definition and understanding of the profession we created through building the current edition.

The important question for practitioners is not whether the current BABOK Guide is perfect, but whether it represents an improvement over having no shared understanding or common definition of business analysis. Mr. Gollner can’t have it both ways. If our practice of requirements analysis is immature, and I agree it is, then someone needs to understand what those practitioners are doing and work on how to help them do it better. A large number of business analysts are still struggling with the fundamentals of our profession, and we don’t need a provable, robust model of organizational improvement to understand that they will benefit from understanding process analysis or facilitation skills or improving their communication skills or improving at any of the dozens of other competencies described in the BABOK Guide. If anyone has a case to make that business analysts and the organizations that employ them don’t need people with those abilities, I’d love to hear it.

Kevin Brennan, CBAP
VP, Professional Development

I started to think about this because I came across Gartner’s definition of EA today:

Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise’s future state and enable its evolution.

Compare that to IIBA’s definition of business analysis:

Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies and operations of an organization, and recommend solutions that enable the organization to achieve its goals.

In both cases, you have a person who elicits information from stakeholders in order to understand and describe what an organization looks like today and what it needs to look like in the future. There seem to be two key differences.

First, the Enterprise Architect is looking at the enterprise as a whole, rather than trying to understand the practicalities of a specific change. Second, enterprise architecture has traditionally been very technology-focused, looking more at the IT architecture than at the business model, processes, and so forth. But then, I hear people saying the same thing about BAs.

A while back, I looked into product management to try and understand how they’re different from BAs, and came to the conclusion that there was a critical difference–briefly, product managers analyze markets, while business analysts analyze organizations. On first blush, though, the difference between EA and BA seems to mostly be one of scope rather than subject.

Comments are more than usually welcome–in case it’s not obvious, I’m asking a question, not stating a conclusion.

Kevin Brennan, CBAP
VP, Professional Development