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.
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. 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 the "Unified" Modeling Language (UML), being deeply rooted in very specific implementation paradigms for information technology. 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, amongst 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 pre-mature, 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.
