Tag: Risk

Watch Out For Think-Holes

Written by Marcos Ferrer on October 1, 2013. Posted in Articles. 2 Comments on Watch Out For Think-Holes

Answer to last month’s question: Change the “head of the fish” to balance benefit as well as cost. Example: “Why does internal service impact profitability?

Most of us have a pretty high opinion of our own thinking*. We are biased, but don’t see it that way. This makes complete sense. WE are ALIVE**. We are the latest survivors of billions of years of disaster, uncertainty, death and taxes***. We are the WINNERS! We must be doing something right. Right?

Right! As survivors, we have tremendous adaptations. Adaptations that got our ancestors away from lions and tigers and bears oh my!**** These adaptations are less useful than they used to be – see if you agree.

Fast thinking vs. slow thinking:

We have almost instantaneous abilities to recognize friends, spot strangers, see (and dodge) dangers, identify objects and their uses, feel body language, judge tone of voice and much, much more. The Nobel Prize winning economist Daniel Kahneman describes these abilities as System 1 thinking.

Here is an example of System 1 thinking:

What is this picture?

Here is an example of System 2 thinking:

If the average expenditure by a middle class consumer ($50K-$115K/year) at a SaveMoreBySpendingMore™ store is $18.25, and middle class consumers represent 94% of SMBSM customers in 2012, and our total customer visits per year in 2012 were 78,543,228, how much revenue came from middle class customers? *****

If the above seems excessive as an example, try this example of “slow” thinking (for most of us):

How much is (40 x 52) – 80?

Even though we “know” we can calculate the above fairly quickly, and we have a sense that the answer is not 17, or 15,000,000, we (I mean I, as my brilliant readers are not so limited) cannot calculate it as quickly as we can recognize a $100 bill.

The “thinkhole” here is the temptation to go with “first intuition” when it is not always the best approach. This can be appropriate (“Duck – here comes a rock!”), it can also be less (way less) than useful (“Let’s build a really cool space airplane just like the astronauts/pilots always wanted. That will be cheap, reliable and fun, just like flying jets.”). One way to characterize a BA is as a person who is willing to do the complex thinking for a larger group.

Anytime a complex decision is offered to a meeting, there is a real danger of the decision being made “quickly”, and almost surely “wrongly”. In such situations we must be ready with clear options and open facilitation to keep discussion (and follow up analysis) alive.

Some of you may recall the training video “Going to Abilene”, where a bunch of IBM trainees decide to go to Abilene after one of them tosses it out as an idea. They have a miserable, hot, dusty day and only get 1 hour in Abilene for their trouble. When they get back to training camp, they argue and place blame until they realize what happened. They went to Abilene because no one wanted to “contradict” their colleague or “put down” the idea. The colleague who suggested Abilene was quite clear. “Don’t blame me! It was just a thought. I didn’t think it was the greatest thought in the world, but when everyone went along I didn’t want to stand out!”

Solution: Do the slow thinking. Don’t force decisions. Simplify for the audience.

Let’s look at some other thinkholes:

Aversion to Loss will prevent Desirable Strategies for Gain

Would you rather have a 100% chance at $1000, or a 90% chance at $1200 with a 10% chance of losing $50? Why? What if you get to play 10 times in a row? It is difficult to overcome fear of loss. The loss can be intangible – reputation, comfort, preference, etc. These fears can actually prevent our work as change agents.

Solution: Do the “math” so all can see the tradeoffs, then duck .

Preferring Apple Pie to Cherry, Cherry to Peach, Peach to Apple

Most individual pie eaters (not all) are consistent (their preferences are transitive, and Apple will beat Key Lime via Cherry), but most groups are not. Politics can illuminate this. In 2000, many democrats preferred Ralph Nader to John Kerry, and John Kerry to George Bush. By voting for Ralph Nader (their first choice), they got George Bush (their last choice).

Those on the left that preferred Nader were NOT happy with Bush, and yet could not make the rational choice – to vote for Kerry instead. Groups can be “dumb”, even when individuals are smart.

Solution: Show choices AND consequences, when it matters.

Overestimation of rare effects

This shows up most often when use case “alternatives” spin out of control. We may be discussing retail transactions, and everyone agrees we should take cash, credit, debit, bitCoin, PayPal and checks. The debate breaks down when we start discussing barter, which is far more complicated (and rare, in commerce). There is no denying that barter happens, AND it may be a waste of time holding up decisions and consensus and progress to handle barter.

Solution: Add it to the alternative paths, and schedule it for LATER.

Misunderstanding probability

This one I want to make money on. If I explain, I won’t make any money. I offer the following bet, without explanation, to anyone who wishes to take it (the law firm of Finch and Associates, LLC will hold the money and administer the bet, unless they don’t want to ):

I am willing to bet my $1 against your $1 that: If we pick 50 people at random, then at least two of them will share the same birthday (same month and day, though possibly a different year).

If that is not attractive we can make it my $5 against your $1 as long as we pick 70 people at random.

Any takers? Why or why not? I have lots more, open your wallets.

Solution: Which humble reader shall provide?

Thanks for reading, leave any thoughts, and have fun!

Don’t forget to leave your comments below.

* Not my humble readers, who know that they are WAY too smart to fall for this.

** Life is clearly biased in favoring existence over non-existence.

*** Us, and Naegleria fowleri, so don’t get too excited.

**** And humans. Next time you are nervous in public, now you know why.

***** Answer next month. No more scroo’n ‘round, on with Thinkholes!

Surviving Residual Risk

Written by Carolyn Ellis on October 1, 2013. Posted in Articles. 2 Comments on Surviving Residual Risk

Those that know me know that I am not one for holding back in life. For some that means that I seem to take a lot of risks in the outdoor pursuits that I enjoy. Cycle to work in Wellington? You must be mad! Go ice-climbing on Mount Ruapehu? Aren’t you scared of falling?!

Yes, there are loads of risks riding your bike to work in Wellington, New Zealand. Given that Wellington is not a cycle-friendly city (understatement) the risks are too numerous to mention. But the key ones I’m aware of have action plans in place to, at the very least, minimise them. Hence the bright clothing, the front and rear lights, not listening to music when I ride, not trusting motor vehicle drivers, pedestrians and animals and, always, keeping my hands close to the brakes. Does this mean I come out of cycle commuting unscathed? Unfortunately not. There’s this thing called residual risk. That’s the risk that is left over once you’ve put all your actions into place. For me that means that, over the past three years, I’ve had a couple of moderate spills. A review of those incidents has changed my action plans. That doesn’t mean I won’t come off my bike again but it makes that ride a little safer than it was before. (Gosh, I hope that this article doesn’t get quoted at my funeral!!!)

And, yes, there is a risk of falling or other negative outcomes when climbing ice waterfalls. Again, put in place some action plans and you’re left with the residual risk. Those plans include checking the avalanche risk in the area, checking the weather, ensuring you have three solid connections to the ice at any one time (that might mean two ice axes into the ice plus the crampons on one foot or crampons on both feet plus one ice axe), having bullet-proof anchors as well as having a more than competent belayer that you trust. With those plans in place the likelihood of an incident are greatly reduced but, of course, never completely removed. Again, there is residual risk involved. Equipment failure could happen. That chunk of ice you’re nicely attached too could fail.

The thing with residual risk is that you then have to review that remaining risk and make a go / no-go decision. Much like we would with a project. We ask ourselves, with that remaining risk, is it wise to proceed or should we stop? That’s the trickiest part and can be the hardest one to get agreement on. That’s when we, as business analysts, need to make sure the residual risk is recognised and the right decision is made. Firstly look at the overall risk factors and the action plans: If I don’t have those three points of contact on the ice, or my bike lights are not working or the reputation of the organisation we are working for is likely to be negatively impacted due to proceeding with the project then we need to have the courage to put the brakes on and stop. If, on the other hand, those three points of contact are solid, the batteries in my lights are fresh or the appropriate mitigations of project risks have been successfully applied, then let’s consider the residual risk. Analyse the likelihood and severity should that residual risk be realised and get agreement on whether to take a leap and go for it or be courageous and call a halt to proceeding.

What have your experiences been (work-wise or personally) where residual risk has been a factor in success or otherwise?

Don’t forget to leave your comments below.

“I Said My Name Is . . .”

Written by Angela Wick on November 20, 2012. Posted in Articles. 1 Comment on “I Said My Name Is . . .”

After several years of experience as a business analyst you begin to see examples of good and bad business analysis everywhere you look: your bank, city hall, the IRS, your grocery store, your cell phone company, etc. We are all end users, customers and consumers.

For better or worse, business analysis collides with many aspects of our personal lives.

Over the course of the last few months, I have been in a fierce battle with bad business analysis—all because of marriage and moving. These are two relatively common life events. Name and address changes should be simple, standard processes. And yet, most organizations fail to successfully manage changes to basic customer data.

My battle started when I realized, after the wedding was over and the witnesses had left the state, that there was an error on the marriage license. My new name was incorrect. I filled out the application properly, but the data on the application did not transfer correctly to the license. A process failed.

Eventually, the marriage license problem got fixed, which allowed me to get an updated driver’s license. Three months later, when I went to vote on Election Day my name on the voting registry was incorrect. It matched the erroneous name from the original marriage license. Now, my ID and voter registration, created by the same organization, did not match! A process failed.

My favorite airline was the source of my next skirmish. In order to get through security, the name on my airline ticket needed to match the name on my driver’s license. My license was “in progress” which means I had a piece of paper instead of the card. Surprisingly, a simple phone call can get tickets re-issued with a different name.

The process to update a frequent flyer account is more complicated—requiring a copy of my marriage certificate and an updated passport or driver’s license. (So no proof needed to change the name on a ticket to fly, but two legal documents needed to help me earn points and get my bags checked for free. Hmmm?)

So for my honeymoon flight, I had to pay for my bags because the frequent flyer name and ticket name did not match, and the documentation needed to get them to match was “in progress”.

The main issue is that the two processes are not connected. I can change my name on my ticket, but until the long frequent flyer change process is complete, I miss points, bags, and upgrades. Ugghh! A process failed.

Once I got the airline situation under control, bad business analysis continued to bombard me via the daily mail. Despite my effort to comply with each organization’s change process, the mail continued to arrive with a humorous variety of names and addresses. My favorite mailing included an envelope, a form letter and a check. All three pieces of the mailing had a different combination of name and address. Many processes failed.

So messing up a name or address change is frustrating and inconvenient, but what if bad business analysis leads to financial loss for the business or customer? What if my financial information, accounting transactions, purchase order modifications, invoices were incorrect?

The quality of an organization’s business analysis affects its bottom line. Understanding and communicating the links or disconnects between policy, procedure, and systems is what gives you value as a BA. BAs prevent risk. BAs minimize loss. BAs prepare organizations to change successfully!

So how can good BAs prevent failed processes and negative customer experiences? Here are a few suggestions:

Create an Event/Response Matrix

An Event/Response Matrix identifies external, internal and temporal events and what happens to the process or system when the event is triggered. If “name change” is an identified event, then analysis would be completed to understand what would happen when “name change” is triggered.

Event/Response Matrices help BAs discover issues and reduce the risk of missed or assumed requirements. “Name change” is a perfect example of assumed requirements. Stakeholders tend to focus on the new features of a system specific to their line of business and often assume that we understand requirements for standard tasks that span the enterprise. We must look “outside-in” with requirements, looking at events outside of the products, systems and business processes; evaluating the impact.

Find the Duct Tape and Bandages

Every organization has duct tape and bandages—little manual processes or databases or spreadsheets or macros that meet a business need but have not been integrated into formal procedures, policies, or systems.

The duct tape and bandages were applied to the business for many different reasons. The primary reason: good leaders found a way to do something cheaper, faster, better while wading through the red tape of official policy or system change.

Identifying and understanding these obscure workarounds can be critical to the success of the organization. We need to evaluate these disconnected practices and determine if they need to be integrated into projects. We need to understand the risks and rewards to determine if the practices should continue or be shared with other parts of the organization.

Understand Interfaces

BAs need to understand how systems share data. Even an informal interface assessment with stakeholders can uncover requirements and minimize project risks.

A few good questions to ask yourself or your stakeholders about interfaces during the elaboration process:

Where else do we use this type of data?
Are there existing interfaces between all of the systems?
Does the current interface meet the business need?
How does data transfer between systems?
How do these systems get updated with new data?
How frequently are changes updated?

Learn About Data Management Strategies

Among other things, a data management strategy defines how an organization moves, integrates, maintains, audits and archives data that is used enterprise-wide.

Does your organization have a data management strategy? Is it comprehensive? Do people actually use it? Is it up-to-date?

Most likely, you will find an answer of “no” or “not really” for at least one of the questions above. So you need to investigate and understand the informal, unwritten data rules in your organization. It is likely these rules will vary across the organization.

So many systems get built and updated without looking at data migration, external events, and the customer experience. BAs add value to the organization when they can anticipate and communicate data management inconsistencies.

Be a Data Integrity Advocate

Given the fact that most companies do not have an effective data management strategy, BAs are left to help business leaders understand the pitfalls of bad or out-of-sync data.

Inform stakeholders how bad data negatively impacts the customer experience and the bottom line. Guide them through decisions about value, risk, and impact.

Today, I am still working through name change processes and resolving errors of the processes I thought I followed correctly! As frustrating as it is, ironically I was in a recent requirements workshop where this exact scenario came up. The discussion evolved and this scenario became a low priority requirement. Why? The volume of customers that get married and move at the same time in a given year is pretty low and the impact and risk to customer value is relatively low. I understand this, and to be fair to my profession, I must conclude that bad data and process is at times the right decision when we must balance value, risk, impact and budget.

Have you bumped into bad business analysis in your day-to-day interactions with companies and organizations? How would you prevent or fix the problem?

Don’t forget to leave your comments below.

The Risk of Documentation Risk Tolerance

Written by Steve Blais on September 18, 2012. Posted in Articles.

This is an open semi-serious response to Mark Monteleone’s article “As a Project Sponsor, What Is Your Risk Tolerance?”

We open with paraphrased lines from Hamlet: Speak the risk, I pray you, as I documented it to you, trippingly on the tongue. But if you ignore it, as many of our players do, I would gladly have the developers and groundlings make it up as they go.

Risk is uncertainty. If we are certain about something, there is no risk. We are certain the sun will rise during the day so there is little to no risk that we will have to endure total darkness. On the other hand, there would be a high risk of personal damage if we were to run blindfolded into a traffic-filled street. If we were sure we would get hit by a vehicle, it also would not be a risk but a certainty. However, we know that it is possible to race blindly into a line of fast-moving cars without injury because we see it happen all the time in the movies! (Do not try this at home. These are professional jaywalkers.)
There are few products that can be defined to one hundred per cent certainty. A space shot comes close because we are certain about the force of gravity, the amount of fuel to escape the pull of gravity, the weight of the rocket to carry that fuel, etc. There might be some uncertainties because we may have never done it before, but some laws of physics are immutable and therefore certain.

When it comes to business, uncertainty reigns. We may only be sure of one thing: we have a business problem. Hopefully we can be absolutely certain that we have the problem clearly defined, but many times that is not even a sure thing. The requirements document, in any form (use cases, user stories, backlog items or a requirements document) states the solution to that problem in greater or lesser detail. That solution is then elaborated or detailed into greater specifications until the solution team can implement it. As the solution is elaborated, we become more certain of what we are doing and the applicability of our solution to solve the problem, and therefore we remove risk.

While there is always a risk that we are not solving the right problem or that we have not defined the problem well, as business analysts we can remove a lot of risk by making sure the problem is not only defined but agreed to by the business community.

When we define the proposed solution, we also remove some risk—we have an approach to solving the problem so the risk of the problem lasting beyond a specific date is now reduced.

A signatory of a requirements document must understand that there is risk inherent in the document. Whether they are actually aware of this is another matter. In my experience, many signatories have not read the document and will never read the document. And regardless, they assume the document assures them that the risk a problem poses to the organization has been removed or at least will be. The larger the document is, the more assurance they feel that the risks are minimized and that the problem is going to be solved. This ties in with lower risk tolerance for larger budgeted projects; the expectation is that a larger budget buys a bigger requirements document. Just as the quality of the document is judged by its weight (the heavier the better), risk reduction is likely also measured in the same way. Can you imagine the response of that $10M project sponsor receiving a couple dozen index cards that describe the solution and being asked to approve them? Consider: “As an astronaut, I want to pilot the space ship to the moon and return safely to the earth within the decade so that I can get a ticker tape parade down Fifth Avenue in New York”. (This is not a knock against user stories, but rather a comment on evaluating risk by document, which as Mark suggests is often done).

However, in business requirements, a signature should only mean, “I agree that this proposed solution will solve the problem. It is the best of the possible solutions we can come up with and I authorize you to proceed with this solution”. To assume that the document itself, no matter how well written, can reduce the risk may be overreaching and giving the document too much credit. Even with all the best practices Mark lists, which should be followed by all definers of business requirements, there is still going to be much more than a ten percent risk that the solution will succeed as defined. The English language has over a quarter million words (according to the OED) and almost each one has multiple meanings. A requirements document, no matter how carefully constructed, will be fraught with ambiguity. That alone creates a high level of risk.

The biggest source of risk is uncertainty. Even if we spend twice the time we asked for to create the requirements document (and we are usually given half the time we ask for, or less), the document would still contain uncertainties. As we gather information to remove uncertainties, additional uncertainties will arise. We are subject to the basic truth of life: the uncertainty of time. We simply do not know what will happen tomorrow.

I think that Mark’s risk tolerance graph is a great guideline to remind us that we can reduce uncertainty by performing the best practices Mark has noted. However, I am uncertain about the percentages Mark assigns, and business analysts can argue forever about what best practices are and what they accomplish. It’s always good to try to simplify a very complex process into some hard-and-fast rules. Human beings like that kind of insulation from uncertainty. Unfortunately, claiming that nine out of ten projects that assiduously follow the best practices listed in the article will be successful is a terribly uncertain and therefore a very risky thing to say. In other words, the model Mark presents has its own risk.

I say this ironically, not negatively. Because Mark has brought up the issue (and the risk) that those reading about risk may decide to reduce the uncertainty of their own requirement documents by following the best practices Mark enumerates and by gathering more information. And that reduces risk. The real question may be whether the project sponsor knows that the extra time (and money) spent performing those practices correlates directly to risk reduction. We are uncertain that the project sponsor has such knowledge, and as Hamlet would say, “Ay, there’s the rub!” Or perhaps, there’s the risk!

Don’t forget to leave your comments below.

Resistance as a Major Source for Requirements Risk

Written by Mark A. Monteleone on June 4, 2012. Posted in Articles. 2 Comments on Resistance as a Major Source for Requirements Risk

This article recognizes resistance as a source for requirements risk. Business analysts recognized assumptions, constraints and dependencies as the major sources of requirements risk. However, in every analysis there is some level of resistance to change. This article reviews the three traditional sources of risk and makes the case for including resistance as an additional source.

What is risk?

Risk is an uncertain event that can have a positive (opportunity) or negative (threat) impact on an endeavor (1). In this context, the endeavor is developing requirements (elicitation, analysis, documenting, and validation), which may be a change to a process and/or software. The result of the development effort is a business requirement document that reflects a stakeholder consensus. Typically, the business analyst recognizes three major sources of risk in planning requirements development:

• Assumptions – business conditions that if changed would affect the requirements or requirements development
• Constraints – conditions that restrict the development of requirements
• Dependencies – requirements that are dependent on other requirements

Change Equals Resistance

The business analyst is a change agent. In developing requirements, the business analyst is inherently involved with change. And, where there is change, there is resistance.

• Resistance is a barrier encountered by the business analyst in developing requirements from stakeholders

Resistance comes in all forms and degrees. Stakeholders typically expressed resistance as a concern or a reservation. However, it may also be to an out-right objection. The key for resolution is for the business analyst to engage in a dialogue with the stakeholder that leads to the reasons behind the resistance (see Figure 1).

Given the above, the business analyst needs to recognize resistance as a major source of risk and manage it as in the other major risk sources. The business analyst needs to identify its possible occurrences, analyze its probability and impact, and develop a risk response. Note that risks that stem from resistance are threats. In this case, the business analyst needs to avoid, transfer, mitigate, or accept the threat (see Figure 2).

A Homestead Example

Dick and Jane are a couple with a nice home and are business analysts for a large firm in a downtown business center. One day Dick and Jane decided to upgrade the single pane windows of their home. Being experienced business analysts, they first listed their major sources of risk (assumptions, constraints, and dependencies) and then prioritized their requirements.

Assumptions
- Continue to live in the home for at least 20 years
- Able to recover window upgrade cost if home is sold
- Energy cost will continue to rise
- Reliable contractor available
Constraints
- Budget is $25K
Dependencies
- Compatibility with current window security screens
Requirements
1. Save energy cost with their home
2. Easy to clean
3. Sound proof

After shopping around for windows, Dick and Jane settled on triple pane energy efficient windows with removable sashes for easy cleaning and a laminated glass sandwich that should squelch out some noisy neighbors. They then picked a contractor that could handle the current security screens and paid the upfront capital for work to begin. All was well until they met resistance.

Remember Dick and Jane live in a nice house, in a nice neighborhood, with a not-so-nice Home Owner Association. Upon the first week of window installation, they received a letter from their HOA advising them to cease all work until they submitted a request to the HOA detailing the change to their house. Although Dick and Jane own their nice home, they have come to realize there is a third stakeholder – the HOA and the HOA can be quite resistant. Lesson learned: always consider four major sources for risk – assumptions, constraints, dependencies, and resistance.

Summary

Business analysts need to manage risk associated with the development of requirements. Traditionally, they consider three major sources of risk: assumptions, dependencies, and constraints. However, business analysts are agents of change. Very few projects, if any, do not incur some level of resistance. Business analysts need to include resistance as a major source for risk along with the traditional three.

References

Project Management Institute, A Guide to the Project Management Body of Knowledge 4th Edition, (Dec. 2008)

Don’t forget to leave your comments below.