What is business analysis?

Comments

• 

  August 18, 2010

  David W. Wright

  Hmm, not bad, may have some legs.

  The toughest concept here is “capabilities”, that word can mean different things to various audiences. “Stakeholders” is OK, and people may discuss what “value” really is, but we know it is not “expense” or “budget” or such.

  Does “Capability” mean what the business does? Is it the processes/procedures with all the resources and technology and anything else it needs to do its business? Are there degrees of Capability? Are they documented in, say, a Business Architecture?

  What gets me, though, is that these definitions never mention Requirements. OK, requirements is not the only thing done within Business Analysis, but it is core to the discipline as practiced today. I have not counted the number of times the word appears in the BABoK, but I bet it outnumbers any other noun.

  Perhaps Requirements are the source of Capability? Requirements are primarily about the defined ability to do something in a business. Is being able to meet those requirements in actuality a business’ capabilities?

  As you can see, some defining terminology can be tricky. The other two main terms are good, so if “Capability” can be defined in a way that is accessible to a wide audience, then this whole definition may be a good improvement.

  Reply
  • 

    August 18, 2010

    David Morris

    Good point. In terms of business architecture: capability focuses on everything an organisation needs to do to achieve specific business outcomes — i.e. more than just processes, it includes resources, technology, and underlying infrastructure.

    Reply
• 

  August 18, 2010

  Julian Sammy

  There is another perspective to consider: what is the purpose of the profession? The definitions above answer the question “What does a BA do?” not “Why does business analysis exist?” I have a hypothesis and theory about this on my site, because I think “why” is an important question.

  Reply
• 

  August 18, 2010

  David Morris

  The ‘why’ might already be covered; to rephrase the above definition of business analysis:

  Business analysis exists because organizations need capabilities that enable them to achieve their vision and mission — which we could describe as delivering value to their stakeholders.

  The first stage of any business change is to define why change is necessary — whether that’s ‘away from’ (i.e. uncovering problems) or ‘toward’ (i.e. assessing solution options) — and defining these as capabilities is useful because this focuses more on what an organisation needs to do rather than how it does it.

  Reply
• 

  August 18, 2010

  Dennis Stevens

  I think capabilities are becoming clear enough. It is what a business does to create value for its customer. It encompasses the resources, policies, processes, and technology. It remains stable even when we change the implementation. So Pay Employees is the same capability whether we do it manually or outsource it.

  I agree that we don’t address requirements though. I want to extend the definition a little.

  How about:

  “Business Analysis encompasses the set of capabilities to assess, define, and communicate the features and organizational changes needed to enable an organization to deliver value to it’s stakeholders.”

  Reply
• 

  August 18, 2010

  David Morris

  Once we’ve defined the capabilities (the ‘what’) then we can move onto identifying organisational, process, and system changes that implement those capabilities (the ‘how’) — these are the requirements.

  So how about:

  Business analysis defines the business capabilities that enable an organization to achieve its goals, and identifies any changes required to implement those capabilities.

  Reply
• 

  August 23, 2010

  Julian Sammy

  The much longer reasoning behind my suggestion is at my blog; the short answer is here.

  Business analysts deliver services that catalyse organizational change, to benefit organizational stakeholders.

  and

  Business Analysis is the set of capabilities needed to provide BA services.

  Expanding ‘capability’ and ‘BA services’ you have:

  Business Analysis is the set of capabilities
  (competencies, skills, behaviours, knowledges and characteristics)
  needed to catalyse organizational change,
  to benefit organizational stakeholders.

  Reply
  • 

    August 23, 2010

    David Morris

    I agree with your statements — although the use of the term capabilities in the opening salvo was around business capabilities rather than the capabilities of business analysts.

    While it would be good to retain that sense of it, I do like your phrasing around catalyzing the organization around change, although sadly not many business analysts have the remit or authority to do that.

    Reply
• 

  August 26, 2010

  Julian Sammy

  I spent a long time on ‘catalyse’, rather than ‘define’. Looking at it now, it’s kind of a modular definition. For example, you might substitue ‘control’ for PMs, ‘build’ for developers and ‘test’ for QAs. That is:

  • · BAs deliver services that catalyse organizational change, to benefit organizational stakeholders.
  • ·PMs deliver services that control organizational change, to benefit organizational stakeholders.
  • ·DEVs deliver services that build organizational change, to benefit organizational stakeholders.
  • ·QAs deliver services that test organizational change, to benefit organizational stakeholders.

  (I like the PM/control bit, but I’m less certain of DEV and QA, and think DESign needs it’s own line.)

  For BAs, the enterprise BAs are on the initiate side of the catalyst, while transition and project BAs have more of the “faster” and “less effort” senses of the word.

  As for capabilities and what they apply to, I thought that ‘capabilities of the business’ and ‘capabilities of the BA’ were too easily confused, so I picked one. Whether that’s the best choice is another matter entirely.

  I’m starting to think that we need a set of definitions that are complementary: what business analysis is, what business analysts do, and why both are needed.

  Reply
  • 

    August 27, 2010

    David Morris

    I like your exploration of of non-technical verbs to describe each role’s responsibilities, as this allows us to highlight the value of each role.

    Perhaps for QAs: ‘assure‘ would describe the value they add rather than just the work they do (touching on the ‘why‘ you were looking for).

    Also, many PMs may be uncomfortable with ‘control’ (as this speaks to the less positive aspects of project management) — perhaps ‘enable‘ would describe the value they add?

    For developers I think ‘build‘ is fine; perhaps for designers it would be ‘design‘?

    I also like your suggestion of a set of complimentary definitions: what it is, why it’s needed, what we do to achieve it, and how we do that.

    From that perspective, I still think ‘business capabilities’ is a useful term to define what business analysis is — we should probably stick to ‘competencies’ when we’re talking about the skills, knowledge, and aptitude of business analysts.

    Reply
• 

  August 27, 2010

  Julian Sammy

  Control is fundamental to what a PM does: they control schedule, spend, effort, project scope (distinct from scope of business need), risk, and much more—and they should, and it’s a wonderful think that they do. The idea that ‘control’ is an inherently negative word (like smell) is interesting. Control is ultimately about power — the capacity to alter the world in intentional ways. In some cultures, it’s inappropriate to wield power. In others it is demanded. Yes, control needs to be balanced if you want success as well—but the same is true for ‘build’ ‘assure’ and ‘invent’.*

  So thinking of control is naughty and undesirable is akin to asserting that fire can only be used for evil.

  _____
  *I’d use ‘Invent’ for design, and ‘build’ for development.

  Reply
  • 

    August 28, 2010

    David Morris

    That comment was more from the ‘agile project manager‘ space — I guess most project managers would be happy being acknowledged for controlling budgets, schedules, and the like.

    This ultimately descends into a word game — trying to capture the essence of the breadth and depth of a discipline in a single verb. ‘Catalyze’ is more what a coach would do, and as you pointed out, only the enterprise BAs are in a space to be able to do that. So we either use the slightly prosaic ‘analyse’ or the better ‘define’ (as it’s more proactive).

    Reply
• 

  September 5, 2010

  Stuart Scott

  Creating agreement on a term like “business analysis” seems to be only slightly less difficult than defining “love,” or “God.” It’s one of those terms that people find useful, even necessary, even though we all know that its meaning varies from person to person.

  I don’t have a definition to suggest – I can only offer my own perspective and preferences. I think I have been most effective at catalyzing change when I have served as a facilitator. In that role, I help to structure and shape conversations among stakeholders as part of an analysis phase of some kind.

  The formal deliverables of these conversations might take the form of process models, data models, use case models, and so on. But to me, these are secondary to the person-to-person agreements and promises they represent.

  I can no longer separate my role as a facilitator from my role as an analyst. Together these roles support a single primary purpose: to enable all the stakeholders of a business domain agree on how they will work together to achieve the goals of the business. They work out and express these agreements using analytical methods and models.

  The initial suggested definition of business analysis at the start of this thread used the word “liaison.” I have misgivings about this word. I don’t like to be a go-between, shuttling from one constituency to another. I think I’m more effective when the constituencies are in direct communication with one another, and I am there to help structure and focus the discussions, to clarify and confirm through the use of models, and to help ensure that all voices are heard.

  I’d welcome feedback.

  Reply
  • 

    September 7, 2010

    David Morris

    Good business analysts do ‘facilitate‘ as a significant part of their role — so it’s good to hear that you do!

    The word ‘liaison‘ potentially reduces the role of business analysis to that of translation, note-taking, or courier — and says nothing about the value that should be added — and that’s why we started this discussion about a definition to replace that.

    So perhaps:

    Business analysis facilitates the definition and development of business capabilities that enable an organization to achieve its goals

    Reply
• 

  March 22, 2012

  JeffC

  “Business analysis defines the capabilities that enable an organization to deliver value to its stakeholders.”

  This sort of definition sounds like some sort of poll test academic double talk that appears to be designed to be just nebulous enough to allow for wildly different interpretations while at the same time confusing those not familiar with BABOK definitions which is nearly every “stakeholder” in the world.

  It is nothing more than a attempt to pull the BA community out the real business world and turn us into an insulated group of “priests” who define the language and terminology to be used when talking about business analysis.

  “Capabilities” and “stakeholders” are two of the most overused and meaningless buzz words in the BA world today …

  The business analyst is totaling unqualified and incapable of defining the “capabilities” of an organization. It is the business users who have the knowledge to define capabilities and possibly identify gaps in those capabilities that could be filled. They define what the organization needs to accomplish or what is holding them back from accomplishing their goals not the BA. The BA may gather that information but in no way should they think they have defined anything.

  An IT project gets started because “the boss” has decided there is a problem that can be solved by said project, period. The term “stakeholder” is an insulting pigeonholing of the multiple layers of managers or partners or owners that a firm may have. Since the lowest clerk in the firm may be by definition a “stakeholder” I don’t think many projects are started to deliver value to those “stakeholders”.

  The business analyst’s job in this case exists to help the end users define just what the problem is. That is the “what”. The BA then can be part of the process of defining “how” will the organization solve the “what”.

  Memorizing the BABOK makes you a housepainter not a portrait artist.

  I have to laugh at Agile proponents (developers all) trying to define business analysis which is given almost no weight in the world of Agile.

  I know developers want to be seen as important and you are, but face it, but the fact is most of you are digital carpenters and not architects.

  Reply
  • 

    March 29, 2012

    David Morris

    @JeffC: thanks for joining the debate.

    Good quality business analysis practitioners are capable of so much more than merely talking to end-users and gathering information — although there are still a lot of glorified requirements secretaries out there.

    The value-add of business analysis comes with our ability and confidence to challenge what people say they need and ensure that it really is part of the scope, that it links back to the objectives of the project.

    The real juice comes in when we work in the enterprise analysis space, directly with the strategy team and/or product managers, helping them frame their roadmaps and define their value propositions, checking what is really needed, that it is feasible, and will provide a return on investment; working with the requestor to define the new capabilities (yes, we do define them); developing the business case; and if the case is approved, then and only then getting a project manager assigned to initiate a project.

    Ultimately the role of business analysis must be to understand the business value to be delivered by any business change initiative, and then to stick to it like glue to ensure that it is not compromised too much by the micro decisions of designers, developers, and project managers.

    As far as the terms are concerned:

    You are right that the term ‘stakeholder’ describes everyone with an interest in the successful delivery of business change — that is deliberate, because they are all important, yet we also know who they are individually too: the customer will be the person who pays, so it is vital that we protect their interests and ensure the voice of the customer is heard; subject-matter experts are vital because they know how the business operates today, what works well and what should be replaced; the product owner is accountable for the business value being realised; the sponsor wants to ensure that their dollars and resources are being spent wisely; and within IT the technical, delivery, and operational teams are also important stakeholders with their own perspectives too.

    The term ‘capabilities’ likewise is a generic term, again deliberately, to force project managers to look more broadly than purely delivery technical changes, that most successful business changes deliver capabilities that are supported by people and processes, as well as technical platforms. When we need to, we use the specific term as well.

    The beauty of language and the strength of an agile analytical mind, is that we are able to chunk up to abstract concepts and chunk down to concrete realities, depending on the context — and are not stuck with a 1980’s monochrome pigeon-holed pen-pushing view of what our role should be.

    Reply

• June 4, 2012

  Pingback: Mastering our purpose | Agile Product Development

  Reply