Operational Risks

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:

• Shoplifters
• Giving too much change to a customer
• A car crashing through the shop
• A customer slipping and hurting themself.
• Goods not the right one
• Counterfeit money
• Robbers
• Fire
• Employee theft

Other kinds of risks are not considered operational risks:

• Another shop opening nearby, drawing some of the customers
• A bank calling on the loan
• Interest rates going up
• Prices of goods going up

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?

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.

Status Your Project with the WBS

The WBS serves as a perfect framework for project status reporting

Your WBS is the list of everything that needs to get done to complete the project.  It’s a ready-made framework for monitoring and statusing the project.

Let’s begin with the basic structure of the WBS:

WBS Code	WBS Description
100	Project Management
200	Product
200.1	Product Requirements
200.1.1	Stakeholder Requirements
200.1.2	System Requirements
200.2	Product Design
200.3	Product Build
200.4	Product Testing
200.5	Product Deployment

If we are going to use this for reporting, we need to include who’s in charge of delivering each WBS Item.  Generally, this can be the Project Manager for that piece of work.

WBS Code	WBS Description	Responsible
100	Project Management	PM
200	Product	n/a
200.1	Product Requirements	n/a
200.1.1	Stakeholder Requirements	Bill F
200.1.2	System Requirements	Jane T
200.2	Product Design	John X
200.3	Product Build	Mary G
200.4	Product Testing	Keith D
200.5	Product Deployment	Sara S

The updated table above shows which manager or lead has responsibility for delivering the work described in each WBS entry.  The items 200 – Product, and 200.1 Product Requirements have no designated responsible person because all the work under them are parcelled out to the work subitems under them.

Now we need to update the table to show the status.

WBS Code	WBS Description	Responsible	Status
100	Project Management	PM	n/a
200	Product	n/a	Started
200.1	Product Requirements	n/a	Started
200.1.1	Stakeholder Requirements	Bill F	Completed
200.1.2	System Requirements	Jane T	70%
200.2	Product Design	John X	NYS
200.3	Product Build	Mary G	NYS
200.4	Product Testing	Keith D	10%
200.5	Product Deployment	Sara S	NYS

In the above update, we see that item 200.1.1 has been completed, 200.1.2 is 70% completed, some of the work are Not Yet Started.  Work 100 – Project Management will have no status because it is ongoing work, while 200 and 200.1 will have only Started at their level. They will become Completed when all the sub-items under them have been completed.

The problem with the above is that it says nothing about whether the project is going according to schedule, going ahead, or being delayed.

For that we can use Earned Values to show the status of the work.

And because the status date of each individual work item may differ, it might be useful to add another column to indicate the as-of status date for that piece of work.

The Project Manager as Disciplinarian

If your project does not have a strong a central organising individual, it will flounder, atrophy, and then collapse.

A project is a collection of talented individuals from many disciplines, individuals with their own agendas and their own visions and their own priorities. This collection falls down into disorganisation without someone providing the structure for the group to act.

Hence it is critical that the project manager be a disciplinarian.  I mean that in the sense that he or she imposes discipline to the group. 

The PM acts as the catalyst that energises the group.  The PM articulates the single vision of the project, makes everyone turn their heads toward that vision, and makes them march together toward that vision.

The PM must be forceful, not necessarily in the sense of overbearing or overpowering but in the sense of being the force that pushes the project forward day by day, prevailing over forces that will tend to rend the group apart into many directions, and keeps it – herds it - aimed in the right direction.

Writing Potent Copy

I borrowed this post’s title from David Ogilvy, arguably the most famous advertising professional. Many professional people who are not in the advertising profession have heard of him, and as a testament to his ability to promote, a lot of these people would find it difficult to come up with another name associated with advertising (I can’t, off the top of my head).

Ogilvy was a great believer in research and in using the knowledge gained from   research to develop successful advertisements. To him, advertising had only one purpose – to get people to buy the product. He claims to have little patience for ‘artistry’, ‘creativity’, ‘novelty’, all of which he considers an exercise in self-amusement by the advertiser at the expense (financially and otherwise) of their client. Sales was of paramount importance.

In the chapter ‘How to Write Potent Copy’ from his book, ‘Confessions of an Advertising Man’, he gives some advice about how to make your copy more memorable. I’ve picked out below some of the most reusable ideas.

The Headline

Advertisements without a headline is an absolute no-no. He calls it ‘the wickedest of all sins’. The reason? Most people read only the headline. If you don’t have one, you automatically give up your chance of hooking your readers. The headline is your tool for grabbing hold of your reader they scan the pages.

Know who it is you are writing for (which is never EVERYONE; it is always a subset of the readership), and use the words that address what they are looking for. His example: if you are selling a product for people with bladder weakness problems, use ‘BLADDER WEAKNESS’ in your headline.

But be careful not to exclude a good number of the people who are not your target. If your product is targeted for senior people with bladder weakness, don’t write headlines addressed to females only. Why risk alienating male readers with bladder weakness?

Always include the brand name in the headline, because most people read only the headline. If that’s all they will read, make sure the product name makes it way into their head. How many times have I seen witty slogans like the one from a moving company: ‘You will be moved by our service’. I remember the slogan, but do not know what their company name is.

The headline should invite the reader to read the body of the advertisement. Make them curious. Make them want to read on. But since you do not have any assurance you’ll succeed in pulling the reader in, make sure the headline stands on its own. It must make sense even without reading the body of the advertisement.

The Body

His advice with regard to the body of the advertisement is simpler less wide ranging. First, be specific and be factual. Avoid superlatives, generalisations, platitudes. Especially in these times when people are swamped in information. Just tell the truth, but make it fascinating (his words).

Testimonials are your best friend. Use them when you can. Ogilvy wrote these words in the early 1960s and notice how prescient they are. How many times do you look for testimonials before buying a product (testimonials and reviews from strangers on the internet!)

Give helpful advice the reader can use. Readers appreciate this.

Write plainly and avoid the temptation to produce ‘literature’. Use simple words so that you don’t fail to communicate what you want to say to the reader. Ogilvy says he once used the word ‘obsolete’ only to discover later that many of his target readers did not know what that word meant.

Transferable Advice?

Is his advice transferable? Many of us are not in the advertising business, but we are all in the sales business. Can you use his insights in the forms of communication you use? I believe so, and I certainly will try.