Comparing the BABOK and the SEBOK, Part 1

I find it interesting that the disciplines of Business Analysis and Systems Engineering share an apparently substantial overlap in their areas of declared responsibilities and specialties.

In the domain of system related projects, both specialise in requirements development, in cost / benefit analysis, in solution assessment and selection, and in verification and validation of the solution.  Could it be they are one and the same thing?

The SE community recently completed its SEBOK Version 1.0 (Systems Engineering Body of Knowledge), available at http://www.sebokwiki.org.  The BA community, through the auspices of the IIBA, has its BABOK (Business Analysis Body of Knowledge), currently at version 2.0 (available at the IIBA website). 

I think it will be interesting to compare the two documents and see what each has to say in areas they have in common, but also in areas which the other is silent.  Where exactly are they similar?  How do they differ?

Since both documents are lengthy, I’ll do the comparisons in several parts. 

To start, let’s look at what each BOK has to say about their particular discipline. 

What is Systems Engineering?

What is Systems Engineering? SEBOK offers this brief definition:

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems

This is a very thin definition, almost to the point of meaningless.  One can probably can use it to describe project management, or even portfolio management, both of which can be argued as enabling the realisation of successful systems. The SEBOK also provides a longer description:

“an interdisciplinary approach and means to enable the realization of successful systems” (INCOSE 2012). It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.

In the glossary, it provides two other definitions, taken from unrelated official documents. The first is from ISO/IEC/IEEE 2010 which says that Systems Engineering is an:

Interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution and to support that solution throughout its life.

The SEBOK also quotes the INCOSE Systems Engineering Handbook (v 3.2.2). The first sentence is exactly the same as SEBOK’s definition:

An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

• Operations
• Performance
• Test
• Manufacturing
• Cost & Schedule
• Training & Support
• Disposal

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

The focus therefore, of SE is defining what the customer needs, and delivering the solution that fills the need.

What is Business Analysis?

The BABOK provides the following:

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.

So, where SE is an ‘approach’ that ‘governs’ and ‘integrates’, BA is a ‘set of tasks and techniques’ and is meant as ‘liaison’. 

The BABOK continues:

Business analysis involves understanding how organizations function to accomplish their purposes, and defining the capabilities an organization requires to provide products and services to external stakeholders. It includes the definition of organizational goals, how those goals connect to specific objectives, determining the courses of action that an organization has to undertake to achieve those goals and objectives, and defining how the various organizational units and stakeholders within and outside of that organization interact.

Here we get some clarity about the focus of BA work: the organisation.

Business analysis may be performed to understand the current state of an organization or to serve as a basis for the later identification of business needs. In most cases, however, business analysis is performed to define and validate solutions that meet business needs, goals, or objectives.

Business analysts must analyse and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The business analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. In many cases, the business analyst will also work to facilitate communication between organizational units. In particular, business analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a “translator” between those groups.

While BA work is clearly meant to identify the customer requirements, it is clear that BA work sits in the non-technical area of the organisation, specialising in what the organisation does and needs.  In contrast, the SE definition does not make it clear whether the SE is more focused on the technical aspects of the solution (we can assume so from the word ‘Engineering, but that is not the same as having it asserted directly).

A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.

When you do work that is in the BA domain, you are doing Business Analysis, regardless of title.  So if you are an SE, you might also be a BA.

I’ll continue the comparison in another post.

ISO 31000:2009’s Definition of Risk

As anyone involved in risk management knows, a couple of years ago the ISO published their new Risk Management Standard known as ISO/IEC 31000:2009 (ISO 31000 for short).  This standard is new for ISO, and is not replacing an older ISO standard.  For countries like Australia though, which had its own standard (AS/NZS 4360:2004), this new ISO standard supplants that older standard.

One of the innovations coming from ISO 31000 is a new definition of risk.  It is a  concise definition, albeit but strangely phrased. It defines risk as:

"the effect of uncertainty on objectives."

At first glance, it looks straightforward.  But a closer interpretation of the words makes on pause: the what of what on what?  

But before we delve into what it means, let’s compare this definition with the one used in AS/NZS 4360:2004, which was not only the Australian (and New Zealand) standard, but also adopted in several other countries.  As testament to its wide acceptance, the core of ISO 31000, its Risk Management Processes, is taken almost verbatim from AS/NZS 4360:2004.

This is how AS/NZS 4360:2004 defined risk:

"the chance of something happening that will have an impact on objectives." 

Here it’s clear that risk is clearly tied to "something happening".  Risk is an event or a circumstance (together with its chance of happening).

By contrast, in the new ISO definition, risk is the "effect of uncertainty".  What is this ‘effect’? 

ISO 31000 provides an explanation:

Effect - "a deviation from the expected -- positive or negative".

Now, since we are talking about risk, and risk is about future events, we can safely assume that when they say ‘deviation’, they are talking about potential deviation, or a possible deviation, not a deviation that has already happened.

If we take that meaning, then it seems to me that the definition of risk can be translated to:

"the possible deviation … on objectives."

This makes some sense.  Risk is indeed about its possible deviation on our objectives.  We hope to finish a project within 6 months, but it might end up finishing after 17 months. 

But notice that I put in ellipses.  The reason I did that is because if I restore the missing words, the definition of risk becomes:

"the possible deviation of uncertainty on objectives."

Which is clearly gibberish, so let’s parse it further.

In risk management, the word ‘uncertainty’ refers to ‘ignorance’ or ‘lack of knowledge’.   ISO 31000’s definition is aligned with this view:

Uncertainty - "the state, even partial, of deficiency of information related to understanding or knowledge of an event, its consequence or likelihood."

Note the definition: ‘Deficiency of information’, lack of information, or lack of knowledge.  This lack of knowledge, does not, I believe, refer to lack of skill, or lack of expertise, but specifically to lack of knowledge about what will happen. 

Given the above, a possible rephrasing of the definition can go like this: 

Risk - the possible deviation, arising from lack of information, on objectives.

The key difference is that in AS/NZS 4360:2004, risk is an event, whereas in ISO 31000, risk is the deviation.  This is not the consequence, but the deviation. 

So for example, we launch a product which we estimate will bring in $20 million dollars.  For AS / NZS 4360:2004, a possible risk is that a competitor might launch a similar product which changes the market dynamics, resulting in lower revenues for us.  For ISO 31000 a risk might be that sales are not as big as we expected.  What are the consequences of that?

This change in the definition of risk has been met with praise, criticism, and confusion.  One of the primary impetus in redefining risk is the desire to better incorporate the handling of ‘positive risks’ in the risk management process.

It certainly makes one rethink.

Risk Management Bibliography / Library

Some key works on various risk management topics either in my library or I have read.  I plan to update this list every now and then.

Risk, Risk Management, and Uncertainty in General

Aven, T. Misconceptions of Risk. Chichester, West Sussex, U.K.: Wiley, 2010.

Bernstein, Peter L. Against the Gods: The Remarkable Story of Risk. New York: John Wiley & Sons, 1996.

Kammen, Daniel M., and David M. Hassenzahl. Should We Risk It?: Exploring Environmental, Health, and Technological Problem Solving. Princeton, NJ: Princeton UP, 1999

Moore, P. G. The Business of Risk. Cambridge [Cambridgeshire: Cambridge UP, 1983.

Morgan, M. Granger. Risk Communication: A Mental Models Approach. 2002

Rowe, William D. An Anatomy of Risk. New York: Wiley, 1977.

Wilson, Richard, and Edmund A. C. Crouch. Risk-benefit Analysis. Cambridge, MA: Harvard Center for Risk Analysis, 2001.

Yoe, Charles E. Primer on Risk Analysis: Decision Making under Uncertainty. Boca Raton, FL: CRC/Taylor & Francis, 2012. Print.

Business / Enterprise Risk Management

Culp, Christopher L. The Risk Management Process: Business Strategy and Tactics. New York: J. Wiley, 2001.

Fraser, John, and Betty J. Simkins. Enterprise Risk Management: Today's Leading Research and Best Practices for Tomorrow's Executives. Hoboken, NJ: J. Wiley & Sons, 2010.

Hampton, John J. Fundamentals of Enterprise Risk Management: How Top Companies Assess Risk, Manage Exposures, and Seize Opportunities. New York: American Management Association, 2009.

Monahan, Gregory. Enterprise Risk Management: A Methodology for Achieving Strategic Objectives. Hoboken, NJ: John Wiley & Sons, 2008.

Young, Peter C., and Steven C. Tippins. Managing Business Risk: An Organization-wide Approach to Risk Management.  2001.

Project / Program Risk Management

Chicken, John C. Managing Risks and Decisions in Major Projects. 1994.

Conrow, E. H. Effective Risk Management: Some Keys to Success. Reston, 2nd Ed. 2003.

Dorofee, Audrey J. Continuous Risk Management Guidebook.  1996

Operations / Operational Risk Management

van Grinsven, Improving Operational Risk Management. Amsterdam: IOS, 2009.

Banking and Financial Risk Management

Bessis, Joël. Risk Management in Banking. New York: Wiley, 2002.

Greuning, Hennie Van., and Sonja Brajovic. Bratanovic. Analyzing and Managing Banking Risk. Washington D.C.: World Bank, 2009.

van Grinsven, Risk Management in Financial Institutions: Formulating Value Propositions. Amsterdam: Delft UP/IOS, 2010.

Safety and Risk Management

Duffey, R. B., and John Walton Saull. Know the Risk: Learning from Errors and Accidents : Safety and Risk in Today's Technology. Amsterdam: Butterworth-Heinemann, 2003.