Unity of Purpose
The Trials and Tribulations of Content Management

The Curious Case of Business Analysis

Business Analysis (BA) is a set of activities undertaken to identify, evaluate, categorize, validate, and manage business requirements and to ensure their realization in the effective implementation and operation of solutions. In very simple terms, the domain of the business analyst is the definition and management of product scope, with this providing the core component for project scope. Project managers, by way of contrast, assume the frequently thankless task of managing the projects mandated to implement a given project scope.

An International Institute of Business Analysis (IIBA) has been formed in Toronto Canada which seeks to bring to this fledgling domain of Business Analysis a measure of professional formality and discipline comparable to that provided by the Project Management Institute (PMI) for Project Managers.

There is a difference, however between the respective efforts of the IIBA and PMI. In the case of the latter, Project Management has been evolving steadily since at least World War II, when several planning and monitoring techniques were forged out of urgent necessity. During the last twenty years, if not more, Project Management has been a highly visible activity within many organizations and made even more visible with the intrusion of Information Technology (IT) into every aspect of every business. The PMI, accordingly, can be characterized as distilling a large (and some might say sprawling) body of knowledge into a disciplinary framework. Around this framework, certification standards and educational programs have been coalescing and at this time it can be said that these efforts have come a long way towards making Project Management a recognized practice and even an emergent profession.

Benjamin Button

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 premature. This is where making a connection between Business Analysis and Benjamin Button appears apt. Like Benjamin Button, Business Analysis has appeared on the stage with all the appearances of maturity when in fact the practice of understanding and articulating business requirements stands as amongst the least mature aspects of how we design, build and manage solutions. 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 specific incarnations of Entity-Relationship Diagrams (ERD) or applications of the "Unified" Modeling Language (UML), with many of these incarnations and applications being deeply rooted in very specific implementation paradigms for very specific information technologies. For an example of a mismatch between one of these techniques and real business needs, see my earlier post on "Modeling with Stickmen".

As work on the Business Analysis Body of Knowledge (BABOK) has progressed, it is interesting to note that it has been migrating its core focus more and more towards many of the tasks and techniques associated with Enterprise Architecture (EA). This sees Business Analysis concentrating increasingly upon understanding the "structure, policies, and operations of an organization" and the recommendation of appropriate solutions. This may be a positive adaptation but it underscores the fact that the domain of Business Analysis remains very much in a state of flux. This trend may be a less positive adaptation as it might reflect a desire, or need, among the architects of a Business Analysis discipline to seek stability amongst higher generalizations and more "strategic" activities - allowing practitioners to float comfortably above the rough and tumble of articulating and addressing real business requirements.

The battering together of a Business Analysis Body of Knowledge (BABOK), and with it a survey of available "techniques", while premature, is ultimately a constructive undertaking - and largely because it throws into sharp relief the fact that there is, as yet, no stable body of knowledge or practice surrounding business analysis. And this is a problem because, as any seasoned project manager will tell you, the vast majority of project problems emerge from the fact that the product, and hence project, scope that is usually thrust into their hands is neither clear nor stable.

When it is considered how much effort and money is annually expended on implementing solutions that fall short of what is expected or needed, it sinks in that Business Analysis is indeed an area where all organizations need to improve and improve quickly. The effort to bring some order to this field is laudable and overdue, but it should be kept firmly in mind that most of this effort should be directed towards building the necessary tools and techniques, and proving them in practice. Dressing Business Analysis up in the accoutrements of a professional discipline and over-emphasizing the trappings of formal certification runs the risk of appearing comical when the reality is so very different.


Feed You can follow this conversation by subscribing to the comment feed for this post.



I read your post today. I wanted to offer some counter-commentary to some things that you mentioned....and before I get started, I'll just go ahead and notify the world at large that I'm a BA, I'm a member of the IIBA and while I don't care for everything about the BABOK, I have a healthy appreciation for it. This reply may be longer than your article, too; but you kind of struck a nerve and I have to get my blood pressure down somehow.:o)

Ok, so the first thing that I'd like to mention is a correction to the statement you made about business analysis arriving only recently. In fact, it has been around for as long as business processes have been defined and computing systems have existed. You might note that the discipline in the BABOK isn't defined by title, but by execution of specific tasks. Historically, persons have been trying to get their organizations to operate more efficiently for a long time, and there was a natural transgression of those practices into the computing environment when that came around. Research into methodologies to help this effort go way, way back. Business Analysis by formal title has been around at least 30 years that I can vouch for, as my own father was one at IBM and performed many of the functions that I do today. While you might not have heard of it in your professional life, there are those of us that have been professionally pursuing the overarching tenets of analysis for a long time.

You also mentioned that Project Management evolved out of a distinct purpose and or driver. The ability to thoroughly analyze whatever needs analyzing became a disciplined practice also by necessity, though nothing so illustrious as a good ole' fashioned war. Your comments seem to contradict themselves by stating on the one hand that PM started to evolve 70 something years ago, but became a mature framework within the last 20 years. The IIBA has taken similar steps to formalize the profession in much the same way, and should be afforded no less room and time to grow than the PMI. In fact, there are many lessons that the IIBA can learn from the growth, success and mistakes of the PMI that can be immediately factored into building a mature IIBA more efficiently.

I should also note that the formalization of the analysis as a profession is two-fold...at least in my eyes. There are aspiring analysts, as well as professional analysts, that have a vested interest in acquiring standardized knowledge that can be used to enhance quality and career progression, just like in the PMI. However, unlike the PMI, there is not a reasonable and consistent understanding of what business analysis is among many organizations and their professionals that hire analysts. The IIBA is boldly bringing cohesion and definition for the benefit of these people in order that they learn how to utilize analyst assets more effectively.

Analysts are in a unique position to have valuable knowledge that allows them to perform activities that no other role can do properly with a view of the overall picture. This very fact is also the Achilles' heel of the profession, because as soon as an uninformed manager realizes how much a good analyst can bring to a project, the analyst is exploited and the value of that analyst is multiplied while the quality of his/her primary tasks....those immature requirements you mentioned...hits the dirt.

Most every other profession involves doing a few things well. Think about it...PMs manager projects, developers code, architects design, etc...Analysts by the nature of their work MUST be able to adapt and communicate to different audiences using a multitude of methods in order to ensure clarity of purpose and collaboration. The IIBA has gone out of its way to define a solid set of techniques that prepare analysts that study, understand and practice these techniques to walk into ANY situation and be able to adapt in such a way that they can facilitate discussion, bridge communication gaps, translate ambiguities into solid diagrams and documentation and build quality into a project where it didn't exist before....well at least until a PM with tunnel-vision on the delivery date and budget gets in the way.

In reality, the PM and BA are the perfect compliment to each other, and I think that the IIBA recognizes that the BA must have a skill set to support analysis disciplines, which is OUR driver for maturity. They offset a whole host of quality killing factors on a project. What better way to ensure we analysts have these skills than to implement a certification exam for us to prove it.

Sorry for the rant, but I, just me talking here, think a little more respect is in order for the efforts of the IIBA...as well as a little less disrespect of many professional analysts that take their roles very passionately and probably don't care for the minimization of their value to an organization.

Very Humbly Yours
Doug Goldberg

Joe Gollner

Hi Doug

First off, thank you for such a considered and comprehensive comment. And you are right, your comment surpasses my post in terms of length and in some other ways as well. As someone who is sometimes called the "word multipler", whose responses sometimes inflate messages exponentially, I feel I am in the company of a worthy colleague.

My response will be in some ways a counter-commentary on your counter-commentary but only in superficial ways. I believe that with some of the branches cleared away, we will see that we in fact agree on the fundamentals.

My primary counter-comment is to suggest my original post was not cast with any disrespect for the people performing the tasks of business analysis, or the very hard - at times excruciatingly hard - work that business analysis entails. At least I am pretty sure that there is no such disrespect in my heart. I am far too well acquainted with the "rough and tumble" of identifying, managing and, perhaps most importantly defending, business requirements to ever think ill of those who carry that flag into battle.

Buried in my overly cavalier treatment of this subject, is - I believe - a ringing endorsement of the need for business analysts, the work that they pursue, and the formalization of the practice and profession of Business Analysis.

In looking at the history, I do concede that the activity of business analysis has been necessarily around as long as the activity of managing construction efforts (of all kinds) and in fact business analysis probably preceded project management. Someone had to decide that what the Pharaohs wanted was a pyramidal structure with certain specifications and this needed to be documented before the whip could be unfurled.

But even a quick survey of the published literature or the relative states of maturity in the efforts to professionalize the respective practices of project management and business analysis must conclude that the efforts surrounding business analysis are much more nascent. There are a number of reasons for this, with one of them being that as hard and complex the undertaking of project management may be, that of business analysis is harder still and far more complex.

The complexity that surrounds the identification and articulation of requirements, followed by their structuring into a form that can be validated, managed, implemented, sustained and evolved, is such that it does not surprise me that the field of techniques catalogued in the current Business Analysis Body of Knowledge (BABOK) is a wide and seems, as I would expect it to, to be getting wider. It must also be conceded that the work needed to integrate and improve these techniques is a monumental task that, to my mind, is just beginning.

This was my primary premise when invoking the playful example of a young Benjamin Button taking early steps in an old man's body. Strictly speaking, this bit of minor mischief on my part is not saying that the efforts to assemble all the techniques surrounding business analysis into an organized rubric is unimportant. Nor is it suggesting that efforts directed towards showcasing the importance of the task of business analysis, as a function within all organizations larger than a bridge game, is not needed. It is trying to say that the body of knowledge underpinning the practice of business analysis is in need of escalating attention and that it will be a work of years (if it is possible at all to think of this as a task with an end) to integrate and improve the techniques and frameworks at the disposal of business analysts.

So my counter-comment is an endorsement of your premise. I hope that you will grant me some of the points I have raised about the state of the tools available, and profile accorded, to the people who ply the craft of business analysis on a daily basis. I also hope that you can see that there was no disrespect intended to those people and if offence was taken I do apologize. If I was poking fun, and I was, it was gentle and it was directed to the IIBA and it was primarily an encouragement to direct more energy towards advancing the quality of the tools and techiques available to the business analyst - as this is the stuff of which the body of knowledge is made and around which a profession can be framed.


Thanks Joe for your counter to my counter.

Perhaps I just forgot to take my Prozac or something yesterday, which happened to be when I read your post. I do concede that there is a wealth of information about analysis that is only now seeing the light of day, and much of that effort results from professional analysts and initiatives from the IIBA...and I think they are well aware that in starting what they have with the BABOK, they've got a lifetime task to maintain it. Not a bad thing though and I'm grateful to have it.

You're good with me and I will say that even though your post hit me wrong, I love these types of exchanges, as they generally produce fantastic dialog.

I've bookmarked your site here, so I can keep an eye on you going forward.

Julian Sammy

This post has spurred some voluminous responses (see also http://iibablogarchive.blogspot.com/2009/07/perfect-is-enemy-of-good.html). In this case, I suspect "The Cute-iosity Is The Enemy Of Conversation" may be the relevant title. Let me attempt to summarize the points of agreement and disagreement. Please confirm / clarify my interpretation:
- AGREE: The Businees Analysis Profession is an old constellation of competencies (knowledges, skills, capabilities and behaviours) with new recognition and clarity.
- AGREE: Business Analysis is a distinct profession from Project Management, with complementary benefits to project management. Being a  
BA is as challenging as being a PM, but for different reasons.
- AGREE: the Business Analysis Profession is very dynamic (as a young profession should be) and very also very stable as an ancient activity.
- DISAGREE: IIBA and the BABOK have a reputational risk to address: the new packaging of old competencies could lead to a loss of  
credibility for the profession.
- DISAGREE: Enterprise Analysis represents the most stable aspect of the BA Profession.

I have some opinions too - but I have tried to keep them out of this.

Joe Gollner

Thanks Julian for directing me back to the other conversation where I did venture a few contributions. My second comment on the IIBA blog discussion convened to rebutt my post hopefully lays out my read on the general points of agreement and disagreement.

On the specific points that you raise, I will quote and respond to each in turn.

"AGREE: The Businees Analysis Profession is an old constellation of competencies (knowledges, skills, capabilities and behaviours) with new recognition and clarity."

I would probably say that Business Analysis is an emergent practice. The elements that have been in evidence for a long time are a mix of separate practice elements and craft skills. The current initiative is very much one of assembling a multitude of these components and attempting to frame a body of knowledge and with it the basis of increasing professionalization. I tend to use the term "profession" in a specific, even legalistic, way so I am uneasy about throwing it around too loosely. Project Management, for example, is to my mind a maturing practice with aspects of professionalization becoming discernable.

"AGREE: Business Analysis is a distinct profession from Project Management, with complementary benefits to project management. Being a BA is as challenging as being a PM, but for different reasons."

See my preceding comment on using the term "profession" for an explanation for why I will refrain from using it in this context. I do very much agree that Business Analysis provides complementary and indeed essential benefits to those provided by Project Management. I due believe that Business Analysis represents a more challenging envelope of responsibilities and this would not change even if the two domains of practice existed at the same levels of maturity and acceptance.

"AGREE: the Business Analysis Profession is very dynamic (as a young profession should be) and very also very stable as an ancient activity."

I wholeheartedly agree that the domain of Business Analysis is very dynamic and I would suggest that, in the not-to-distant future, it will become a whole lot more dynamic. There are elements within Business Analysis that are fundamental, indeed ancient - the most notable being communication - which all will confess is both the most important of capabilities and the most challenging to ply.

"DISAGREE: IIBA and the BABOK have a reputational risk to address: the new packaging of old competencies could lead to a loss of credibility for the profession."

I think that the primary risk is that energies get diverted towards to trappings of professionalism (such as certification) when the foundation that the body of knowledge is endeavouring to circumscribe is so "uneven", if I can call it that. Some of tools and techniques available in the Business Analysis kit bag are pretty good and some of the above-mentioned ancient capabilities, such as communication skills, are "must-have" items. Others are more novel and even untried while still others are creaking with old age and are perhaps wedded to an outmoded era. The merits of framing an outline and a declared set of principles and goals, and inviting a vigorous discussion and debate around them, is essential if there is to be progress on levelling the foundation.

The risk of pre-mature formalization is perhaps one that the members of the IIBA and the community of Business Analysts are well aware of. There are plenty of examples that can be summoned up that underscore the fact that the risk is real (and that there are interesting forces that encourage it to become ever more real) even if the community is both cognizant and vigilant.

"DISAGREE: Enterprise Analysis represents the most stable aspect of the BA Profession."

I would not say that Enterprise Analysis represents the most stable aspect of the BA domain. I find many aspects of the EA area interesting but I am also aware of many frameworks and initiatives so I don't see it as being very stable at all. I think I gave EA a glancing blow in my original post in part because I tend to come across practitioners of these EA activities comfortably ensconsed in parts of the organization where there is time and leisure to refine models and strategies - and these enclaves don't feel like the coal-face where real requirements are hammered out and bent to reflect changing conditions.

Julian Sammy

Thanks for the conversation, Joe. I subscribed to your RSS immediately upon reading this post. I have used the phrase "Business Analysis is a fractal hierarchy" many times, and usually get a deer-in-the-headlights look. Even if we disagree, I like both what you are thinking about, and I like the way you think.

David Morris

Thanks for the clarifications, both here and on the IIBA blog. It's good to see that people on all sides are open to discourse, although that's sometimes only after the opening rounds have been shot. Provided we can keep to this in good humour and intent, it'll be good. I've enjoyed the thrust and parry, and believe that the nuggets that have been turned out from many parties may not have seen the light of day if it were not for this discussion.

Joe Gollner


This post stirred up some very interesting discussions. See the response by the IIBA and the associated discussion on the IIBA blog. See also the somewhat more measured observations by the Practical Analyst.

My initial comments, which were admittedly cavalier, seemed to have touched a nerve amongst those whose mission it is to advance the standing of business analysts. The core of the response being made to my insinuation that business analysis remains a highly immature domain would seem to turn on illustrating that business analysis, as an activity, has been performed for a long time. This I immediately granted and even, in the above thread, imagined egyptian business analysis polishing construction requirements. That an activity has been performed for a period of time, however, does not make it a practice let alone a profession, and this returns to the point behind my initial post.

An activity that is performed by a community who collectively recognize the tasks being performed by colleagues and who share some common tools is what we should term a craft. When the tools and techniques being used begin to exhibit a discernable level of commonality across a community and measures of success begin to take form, we enter the domain of a practice. It is when the tools and techniques associated a practice become formalized, and when these formalisms achieve a recognized standing outside of the community of practitioners, then we move into the domain of a profession. Under this rubric, business analysis is very much a craft that is making the shift to a practice. In contrast, Project management is amid the transition between a practice and a profession.

The back and forth in the discussions, both here and on the IIBA blog, really stem from a difference in the definitions being used and therefore different criteria for applying a term such as profession. Based on the studies I once pursued in this very field, I tend to use the term profession in a specific way and I cannot divorce it from quite an extensive array of criteria. As I would likely question the maturity of medical profession, as a profession, and this after almost 1,000 years of concerted effort directed towards shifting medicine from a practice to a profession, it should come as no surprise that business analysis is deemed, in my rubric, as having a very long way to go.

There are definitely activities that need to be done, in order to improve the activity of business analysis, and the standing and recognition of business analysts, and among these is included the effort to catalogue the tools and techniques that can be deployed. Others include the effort to forge some better tools and techniques either anew or from assets borrowed from other fields. In the exchanges that followed from my initial post, I repeatedly declared that it was the fashioning of better tools that should be receiving the preponderance of the community's attention - and I did so because this would help working business analysts today.

The Practical Analyst asked a couple of closing questions that do merit consideration. "If not the IIBA, then who?" On this, I would suggest that the work at hand to advance business analysis is not something that can be relegated to, or associated with, a single body. One point I did underscore in one of the exchanges was that the emergence of the medical profession could not be tied to the role played by any one institution. In fact, in the march towards professionalism, it is essential that a number of organizations participate, with educational institutions being a common, even key, player. All that aside, the IIBA has taken the initiative to mobilize the community of business analysts and I do take this to be a singularly good thing and as an essential piece in the evolutionary puzzle. "If not now, when?" Now is a very good time although, after my own experiences in business analysis, I would have liked to have seen the baton taken up even earlier.

Trisha Martinez

As one of the few "Business Owners" who follows this topic, I believe that the practice of capturing Business Requirements for a project has a long way to go before becoming "mature." Every day I see piles of Word documents and spreadsheets being signed off as total "requirements" by the business (although they understand only 50% of what's written,) only to have a system delivered that does not meet the business needs. It feels like Use Cases are written by IT people for IT people to cover themselves. If the system doesn't work like it's supposed to - well, you didn't tell me your requirements well enough. Too bad if anyone who's ever done the business job would have known this requirement - if it's not explicitly spelled out on one of our documents, it's not in scope. If it's not in the use case, well that's a change order and months and months of development with a steep price tag. After these experience, most Business Owners spend precious time trying to detail out every single last "requirement" for new projects. As an example, I once spent two days detailing how many ways I needed to "download an asset" from an asset management system. As if managing assets in a system would be worthwhile without being able to download them! Perhaps the IT folks could meet us halfway and acknowledge that some requirements are so obvious they don't need to be detailed out in three different "views" which will take two full days to do while your e-mail is piling up.

Don't even get me started on what happens when you're in development. Another set of folks gets the documents and spreadsheets and tries to make sense of them, without being in the meetings with the Business Owners. Suddenly, you find yourself taking the same two days to tell another group of people the same thing about your "requirements." I'm always left wondering why I bothered with the first set of meetings and "requirements gathering" in the first place. Why not just start with the developers in the room, and the person who will do the work will get the answers directly - not through third party "documentation" which always fails to communicate the nuances necessary for success.

I'd like to get to a way of communicating requirements that is much more focused on the business and much less focused on IT.

Joe Gollner

Hi Trisha

I definitely agree that the weakest link in the whole "solution chain" can be found around the boundary between business needs, system requirements and the realized (and hopefully evolving) system. And I really do like to differentiate between business needs and system requirements. Use Cases, for example, are really (indeed wholly) dedicated to system requirements and if these are used as the only expression of business needs then there is a fundamental problem. I have ranted about this more specifically in the post entitled "Modeling with Stickmen" (http://www.gollner.ca/2008/02/modeling-with-s.html).

I have myself been trying to explore ways to better fill this gap. For example, I have been addressing this recently under the name "content scenarios" (http://www.gollner.ca/2011/11/introducing-content-scenarios.html) although I am planning to renovate this post somewhat. And this was a subject that I tackled way back in 2000 in a white paper called "XML Business Templates" (http://www.gollner.ca/papers.html).

In trying to bridge some of the gaps, I have (on several projects) applied various methodologies including those travelling under the Agile banner. These definitely resolve some of the problems but I also find that they introduce other challenges. Among these challenges is that these approaches do tend to downplay documentation and this can be a problem when there are contracts to manage, deadlines to hit, etc etc. Perhaps more seriously I find that face-to-face communication strategies, say between developers and business stakeholders, can run into their own troubles (some acknowledged and avoided, and others unacknowledged and simply incurred). On the acknowledged side of the trouble equation is the fact that these conversations are fundamentally hard so in many an agile project the fact is that the process tends to drift towards being conversations amongst developers. On the unacknowledged side is the conformity that often surfaces out of face-to-face exchanges (a fascinating topic all on its own) and the fact that it doesn't actually tackle one of the core problems which is helping business stakeholders to build consensus around possible future states given the capabilities of some of the technology and techniques available.

It is a pickle, no doubt about it. But I remain hopeful that there is a way to bridge the domains...


Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)