Skip to main content

Tag: Risk

Bad-Ass BA Lessons. Part 2

Co-Authored by Cecilie Hoffman

This article is a continuation of the 10 Steps to Becoming a Bad Ass Business Analyst. These steps will help you take your professional capabilities beyond most people’s expectations and help you to stand out as a leader. In the first installment we covered:

Step 1. Exploit the hidden power in “menial” tasks
Step 2. Delegate!
Step 3. Compose in real time
Step 4. Define gonzo success criteria

Let’s move on to activities that establish you even more into a leadership role.

Step 5. Ask the Crazy-as-a-fox Stupid Questions

Slang: “crazy as a fox” – the fox is considered a cunning creature who may choose to act in a manner that appears to be foolish or stupid, but actually advances its underlying plans, or, in the case of fox hunting, outwits its pursuers and saves its life.

All business analyst job descriptions should have these four expected duties:

  • Asks the questions that no one else dares to ask, and that everyone wishes somebody would ask.

“I’m not sure I’m following, it sounds like we have made an assumption that magic happens at this point in the process, and all the customer record duplications are cleaned up and removed. Could you tell me again how this is going to happen?”

  • Asks the questions that, once answered, will bring everyone to the same level of understanding.

It may be the case that some people in a meeting know what a particular TLA (three letter acronym) means, but others have no clue, and are having a hard time following the conversation. The “stupid” question, “sorry to interrupt, but could you tell me again, what SRM stands for?” isn’t stupid, it is a kindness.

  • Crystallizes the issue for people to understand what the sticking points are.

You may need to go out on a limb and take the risk of oversimplifying, but it is a risk worth taking. For example, it is not unusual for two team members to be arguing vociferously when they are actually in violent agreement. It’s your job to remove their blinders and show them how their opinions can actually dovetail. Try paraphrasing their positions, and then suggest how they can be combined.

“Let me tell you what I’m hearing. Lakshmi, you feel that A is the most important issue. Jorge, you’ve been saying that B has to be addressed first. I don’t think this is a win-lose situation. Your recommendations are not mutually exclusive if we do C, which essentially combines A and B. As for D, can we forgo it? Doing so would remove the risks we are concerned about. What would the ramifications of that approach be?”

  • Ask the questions that lead to out-of-the-box thinking.

One interesting “stupid’ question involves asking for the anti-solution and using the resulting suggestions to generate discussion on how to resolve those problems.

“Let’s spend a few minutes thinking out-of-the-box with the anti-solution. If we really wanted to mess this situation up, what would we do? [much laughter and crazy suggestions which you capture as discussion points] And how can we avoid point A? What about point B – aren’t we actually making that worse with this requirement we just defined? Does this raise the possibility of an entirely new solution/policy/process?

Step 6. Get Their Attention

Slang: A “clue-by-four” is a broad hint, firmly delivered. Also a metaphor for enlightenment. This term derives from a western American folk saying about training a mule: “First, you got to hit him with a two-by-four. That’s to get his attention.” A two-by-four is a standardized size for boards used when building – roughly 2 inches thick by 4 inches wide by multiple feet long.

People, unfortunately, don’t always pay attention to potential risk. Risk as seen through our BA eyes frequently has to do with the consequences of missing information. This kind of risk can be overlooked or underestimated by people who usually focus on delivery risks. The clever BA needs to not only identify the risk, but also assess the severity of the risk, and frame and communicate the risk in a way that makes the consequences clear and unappetizing.

The fact that Risk Management is usually considered a project management activity does not preclude a BA from putting this methodology into her own toolkit:

  1. Identify, characterize, and assess threats
  2. Assess the vulnerability of critical assets to specific threats
  3. Determine and quantify the risk severity and likelihood of occurrence
  4. Identify ways to reduce or avoid those risks
  5. Prioritize risk reduction measures based on a strategy

Capturing this information in a tool like the Failure Mode and Effects Analysis (FMEA) permits you to share it with the stakeholders and get their agreement on the existence of the risk and buy-in to the risk avoidance and diminution methods. Then, when the stakeholder isn’t paying attention to a promise or deliverable, you get the joy of saying, “Madam Stakeholder? I just wanted to gently remind you that three weeks ago you promised to provide me with headcount of your developer teams so that we can estimate the number of licenses that will need to be negotiated for this third party application. According to the agreed upon risk management plan, if we don’t have the information by tomorrow at 5 pm your local time, we will have to defer all the requirements from your organization until the next phase of the project.”

Risk Management is traditionally the responsibility of the project manager. However, identifying risk is an activity that falls squarely in the lap of the savvy business analyst. Take some time to become familiar with it and the tools to support it.

Step 7. Schmooze Those Stakeholders

Slang: “schmooze” means to chat in a friendly and persuasive manner, especially so as to gain favor, business, or connections. Derivation: “schmooze” came into the English language from the Yiddish language shmues, meaning talk.

Stakeholders have the power to help you or hurt you, and if you surprise them with something, they will almost always hurt you. Make sure that they know when something is happening in your project that will touch their sphere of influence and that they buy into the change.

When you identify your stakeholders, those with the most power to help or hurt your project are the High Priority stakeholders, and should be regularly schmoozed by you and/or one of your key team members. At a minimum, meet with them regularly to keep them apprised of the project’s progress and potential impacts on their area of influence. Make sure they know who is supposed to be representing their interests, and make sure you understand what those interests are. Ask them what their success criteria are for the project, and if their idea of success is not in line with the project’s goal, perform proactive change management. Build bridges and help them understand that you are looking out for them. You will undoubtedly have to deal with them again in the future.

Step 8. Rat Out Those Underachievers

Slang: to “rat out” is to inform on, or tattle.

You’ve presented your requirements gathering plan; you believe that there is a shared understanding of the strategic direction and everybody has signed up to do their share of the work. A couple of weeks go by and everyone has completed their commitments but one team, Team Slowpoke. You did everything to ensure that all the work would come in on time. You called them a couple of days before the deliverable was due and asked how they were doing. You got a non-committal answer and they said they didn’t need help. The day of deliverable came and went. You called the next day and said that you must have missed their email with the deliverable and would they resend it. By noon. Today, Thursday. Noon came and went. It’s Friday 10 am. The entire team meets at 8 o’clock Monday morning. What’s a bad ass BA to do?

You can talk to the laggards’ peers, expressing your concern, and encouraging them to put pressure on the laggards. In parallel, you can talk to your manager and express your concern. No whining, just concern.

“Mr. Manager, I just wanted to let you know that all the teams have provided the information that they agreed to provide, except for the Slowpoke team. They have said they don’t need help. They aren’t responding to email, or voicemail, and no one is in their office. I’m concerned about what we can accomplish in our Monday meeting given their lack of participation.”

Finally, in the 8 a.m. Monday meeting, you can review all the deliverables and their status, thanking all the other teams for delivering on time, and calling attention to Team Slowpoke’s failure to deliver. You can ask Team Slowpoke’s leader, in the nicest possible way, to explain why this failure occurred so the rest of the group can help resolve the problem. You remain silent, maintain eye contact, and listen. Then you can ask how they intend to resolve the problem and what the new due date will be. In fact, you might even offer to talk with their manager, in case this is a resourcing problem and the team needs to have something taken off their plate. Use your sense of judicious audacity here, to determine how far this needs to be pushed.

The worst thing you can do is do nothing.

This is the second installment in this three-part series. In the next installment we’ll talk about speaking truth to power and that all important BA accessory, the Facilitator’s Flak Jacket.

Installment 1

 

Step 1. Exploit the hidden power in “menial” tasks

Step 2. Delegate!

Step 3. Compose in real time

Step 4. Define gonzo success criteria

Installment 2

BA Times

July 14/09

Step 5. Ask the crazy-as-a-fox stupid questions

Step 6. Get Their Attention

Step 7. Schmooze those stakeholders

Step 8. Rat out those underachievers

Installment 3

BA Times

August 11/09

Step 9. Speak truth to power

Step 10. Put on your “Facilitator Flak Jacket


Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected]

The Language of Alignment

Business benefit, growth, and profitability. Cost and risk. Value add. Forecast confidence. Customer satisfaction and loyalty. These are the measures of senior management. And if the goal of a commercial enterprise is to make money now and in the future, everyone in the enterprise needs to be behind that goal.

You manage a business unit and are looking at a red/amber/green dashboard report of your current programs, and you see that one is red. With your browser, you drill down the trail of red, each click bringing you to a lower level dashboard with more detail about a specific aspect of the at-risk program. Here is what you find:

  • The business’s success with a new product line is at risk because
  • The sales teams might not be prepared to sell the new product line because
  • Sales training for the new product line may be delayed because
  • Implementation of the Learning Management System (LMS) may be delayed because
  • The LMS module used for the management of training records may be delayed because
  • Development of the core code library for that module may be delayed because
  • The lead developer may need to leave the project due to an important and urgent personal matter

While the above may seem dreamy, it’s where we’re headed. Everybody in a value supply chain, from the lead developer to the LMS implementation project lead, to the sales team manager, to the business unit manager should, at any point in time, be able to express the status of his or her responsibilities in terms of Cost, Risk and Business Benefit.

The costs, risks, and benefits of what, you may ask? Simply put, for each person or team in the value supply chain, the costs, risks, and benefits of meeting their requirements.

Previously I have argued that the requirements management activities of planning, eliciting, etc. are necessary regardless of the domain in which one is working (instructional design, business strategy, database design, etc.). It is not only possible, but necessary, that requirements managers in those domains be able to express their status in terms of cost, risk, and business benefit. Rolling up requirements status to a senior level necessitates a common language, and that language is defined by the top-level requirement(s) of the enterprise.

We have much to do. In my next post, we will elaborate on the above and identify the top three challenges in achieving the dream.

Do you have any thoughts or questions about this post and earlier posts? Please don’t be shy! Let us know what you’re thinking by adding a comment below.


Terry Longo
has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/sections/pm_bus_analy.html

or at [email protected]