Value Investing
Calandro, Joseph. Applied Value Investing: The Practical Applications of Benjamin Graham's and Warren Buffett's Valuation Principles to Acquisitions, Catastrophe Pricing, and Business Execution. 2009.
Graham, Benjamin, and David L. Dodd. Security Analysis. 1996.
Graham, Benjamin, and Jason Zweig. The Intelligent Investor. 2003.
Klarman, Seth A. Margin of Safety: Risk-averse Value Investing Strategies for the Thoughtful Investor. 1991.
Knowledge Areas are subject matters of core interest to a profession or discipline. They are the sort of knowledge often required to live the profession. In the medical profession, a knowledge area might include physiology, how the body functions. For project managers, an example might be scope management.
Knowledge Areas
For the BABOK, Knowledge Areas:
define what a practitioner of business analysis needs to understand and the tasks a practitioner must be able to perform.
In other words, it is an area that a Business Analyst should have knowledge on.
For the SEBOK, Knowledge Areas:
are groupings of information with a related theme
The SEBOK is reluctant to assert that an SE must know about the Knowledge Areas (henceforth KAs), whereas the BABOK claims the KAs are what the BA ‘needs to understand’ and ‘able to perform’. The difference in these scope will become evident as we look at the KAs listed by each of the BOKs. We can now say that the BABOK KAs are far more modest in scope than the SEBOKs.
The BABOK Knowledge Areas
The BABOK lists seven KAs:
The BABOK KAs are closely related to skills. One can develop ‘Business Analysis Planning and Monitoring’ skills, or ‘Elicitation’ skills.
The SEBOK Knowledge Areas
The SEBOK not only lists far more KAs than the BABOK, but the breadth and depth of the subject matter is in a different league.
The SEBOK KAs are divided into 5 Parts, each of which has KAs under it. Here’s the full list of Parts and KAs under them:
The SEBOK list of KAs is comprehensive, ranging from the abstract subject of Systems, down to performance assessment of individual SEs.
At a first approximation, it seems to me that the scope of the BABOK KAs fall within this subset of the SEBOK KAs
No surprise, SE is far more broad than BA if the KAs are to be the basis. But that is not the main point of this series. The key interest is where they overlap. We will look more closely at these overlapping KAs in the next parts.
Business Analysis and Systems Engineering seem to share a substantial in their perceived areas of scope, so it might be informative to see what their respective BOK Guides say about the other discipline.
Do They Know Each Other?
It is interesting that neither the term “Systems Engineering” nor its variant “System Engineering” appear in the BABOK. This is strange because the BABOK authors are evidently aware of the SE discipline, since the BABOK Bibliography includes these two SE-centric books:
Stevens, Richard, Peter Brook, Ken Jackson, and Stuart Arnold. 1998. System Engineering, Coping with Complexity
Forsberg, Kevin, Hal Mooz, and Howard Cotter-man. 2005. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems
As for the SEBOK, it mentions “business analysis” three times, each time using it as a synonym for mission analysis, such as in this extract:
MA, in some domains called market analysis (glossary) or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise (p. 253).
Judging from this, the SEBOK considers business analysis as limited to mission analysis, which is only a part of the Concept Definition Phase
What is Business Analysis?
If Business Analysis is synonymous to Mission Analysis (according to SEBOK), it should be useful to compare and contrast BA as understood by the BABOK with MA as understood by the SEBOK.
The table below lists the functions of BA as described by BABOK, and the functions of MA as described by SEBOK. I tried to match them, with some degree of interpretive freedom on my part.
| Business Analysis | Mission Analysis |
| Liaison among stakeholders | |
| Understand the structure, policies, and operations of an organisation | |
| Recommend solutions that enable the organisation to achieve its goals | Analyse the solution space |
| Understanding how organisations functions to accomplish their purpose | |
| Defining the capabilities an organisation requires to provide products and services | |
| Definition of organisational goals | |
| Define how goals connect to specific objectives | |
| Determine courses of action that an organisation has to undertake to achieve those goals and objectives | |
| Defining how the various organisational units and stakeholders within and outside the organisation interact. | |
| Establish a set of stakeholder requirements for a potential SoI (System-of-Interest) | |
| Focuses on the identification of the primary purpose(s) of the solution | |
| Part of the larger set of concept definition activities - | |
| Understand a mission / market problem or opportunity | |
| Initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity | |
| Define operational actions, not hardware / software functions; that is, it is focused on defining the problem space, not the solution space | |
| The primary products of MA are the revised ConOps of the enterprise, the | |
| MA evaluates alternative | |
| MA defines the problem space |
I could not match the two sets of functions and find very little, almost no direct intersection between what Business Analysis is according to BABOK, and what Mission Analysis is according to the SEBOK (which treats business analysis as a synonym for Mission Analysis.
And yet, my instinct tells me there is a strong intersection, it’s just that the two BOKs use very different terminology and very different ways of explaining. (I find the BABOK a bit more refined in its explanations, while the SEBOK tend to ramble a bit).
Number of Pages
This is an easy comparison. Version 2.0 of the BABOK has 253 pages. The SEBOK is primarily laid to for reading online using a Wiki platform, but a PDF version is available for download. This PDF runs to 850 pages. Better have a full ream of office paper ready if you decide to print this.
Authors
The SEBOK lists 70 authors, some of whom I recognise as respected leaders in the SE discipline. The ones I know by reputation include: Barry Boehm (but I know him from the software engineering field, not the SE field), Erik Aslaksen, Edmund Conrow, Dov Dori, Kevin Forsberg, and James Martin.
The BABOK also credits as Content Contributors about 19 names, of whom the only one I recognise (but recognise only the name, not what she’s about): Ellen Gottesdiener. They do have an Expert Advisory and Review Group, from which I recognise the following names: Scott Ambler, Dean Leffingwell, Meilir Page-Jones, James Robertson, Suzanne Robertson, Steve Tockey.
Operational risks are those risks related to failures in day to day operations. They are different from other kinds of risks such as credit risk, or market risk.
Operational risks are about things going wrong resulting in losses. For example, a small grocery might encounter the following problems:
Other kinds of risks are not considered operational risks:
Operational risks are about failures of people, systems, and processes, and about external events.
The risk brought about by operational risk, like any risk, depends on the likelihood of occurrence, and the consequences it brings. These costs need to be balanced by costs related to mitigating the risk. For example, the risk of being robbed may be mitigated by hiring guards to secure the store, but will the cost of hiring them be higher than the cost of being robbed, once or twice a year?
The cost of being passed counterfeit bills may be mitigated by installing a counterfeit checking device, but will that cost more?
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.
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.
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.
The company DeepLearning.AI offers a free online course called "ChatGPT Prompt Engineering for Developers" from Coursera. Large L...
