Articles Archives - Page 377 of 417 - Business Analyst Articles, Webinars, Templates, Jobs

You Won’t Die … I Promise!

Written by Kupe Kupersmith on August 18, 2009. Posted in Articles.

Kupe’s Korner

We are all human; at least I think we are, so it is in our nature to get comfortable in a routine. I wake up around the same time every day. I have a consistent workout schedule; eat breakfast at a certain time; get to work and leave work around the same time.

We tend to do the same thing when it comes to business analysis. We use the same techniques to elicit requirements, analyze requirements, and present them. It makes sense. The more we do it, the better we get, and the more we want to keep doing it. All of this sounds great right? Wrong! I say this a lot so I apologize if you’ve heard me say this 100 times before. Every project is different. Every stakeholder we work with is different for each project, even if we have worked with them for years. A stakeholder’s involvement and excitement for projects may be different. Their availability may be different, the list goes on. If every project is different we need to approach each one differently.

“The only person who never makes mistakes is the person who never
does anything.” – Denis Waitley

As analysts we can’t stick with what we know. We must find ways to add more tools to our tool box. If we stick with what we know, that’s what you’ll be known for and be called on when those skills are needed. What happens when you stop getting called? You need to stay in the mode of constant growth and learn new techniques. I’ll be the first to admit, I am still growing and learning.

“Only those who dare to fail greatly can ever achieve greatly.” – Robert F. Kennedy

The fact that we need to know so many different techniques goes to the core of why it is almost impossible to develop consistent job descriptions for BAs; why you can’t just say a Business Systems Analyst position at company “A” is the exact same job at Company “B”; why it is so hard to distinguish between a junior level BA and a Senior BA; why companies struggle with career paths for BAs.

So how do you continue to grow? The easy answer is to take training classes, read books and read the check the reams of information online. Anyone can do that, and I know you don’t want to be doing what everyone else can do. That’s the easy way. You want to be in the top 10% of people that every company wants.

RT @ PaulVHarris If Columbus gave in to his fears, no one would have blamed him. Of course, no one would have remembered him either.

Every now and then you need to jump off the easy road and take risks. I promise you will not die. Yes, it’s scary sometimes just going for it, but what is the best way to learn? Right, by doing it over and over again.

“I am always doing that which I can not do, in order that I may learn how to do it.” – Pablo Picasso

The mindset to have is like a politician not running for re-election. They start saying it like it is because they are no longer worried about losing their job. When you know a certain technique will be best for a situation, do your homework, then go for it.

“Don’t be afraid to go out on a limb. That’s where the fruit is.” – H. Jackson Browne

Another thing you can try is volunteering for projects in relatively unfamiliar business areas. Will it be as easy as the business area you have worked in for five years? No, but think of how you added to your knowledge base. Now you can be the one they’ll call on for other business areas.

“The pessimist sees difficulty in every opportunity. The optimist sees the opportunity in every difficulty.” – Winston Churchill

How far you can go is up to you. You can sit back and enjoy the ride. Or you can take the more difficult path now and then.

“Those who try to do something and fail are infinitely better than those who try nothing and succeed.” – Lloyd Jones

Enjoy your ride,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected]

Projects without Borders; Gathering Requirements on a Multi-Cultural Project

Written by Elizabeth Larson on August 11, 2009. Posted in Articles.

Co-authored by Richard Larson

One of the most difficult tasks project managers and business analysts face is obtaining customer requirements. Even when business customers and the business analyst work in the same building, misunderstandings are bound to arise. And as more and more businesses expand beyond their borders, different terminology and ways of doing things the risk of things going awry gets even greater. It’s a challenge to ask the right questions, get the right people involved, and document unambiguous requirements, regardless of the backgrounds of those participating. When the project includes multi-cultural stakeholders, particularly if they comprise a virtual team working in geographically dispersed areas, often thousands of miles, time zones and oceans apart, the job becomes much harder.

Some of the challenges facing project managers and business analysts are not unique to multi-cultural projects. However, personal agendas, conflicts about roles and priorities, and availability worsen the situation. In addition, recent studies have shown that almost half of the typical project budget is spent reworking requirements defects. While there are many underlying reasons for this rework, dealing with a group of multi-cultural business customers and/or project team members can create significant hurdles.

The Challenges

Physical Distance of Stakeholders

Although many of the challenges exist even when the team and business customers are located on the same floor in the same building, the difficulties in dealing with them increase with physical distance. Time zones make meetings hard to schedule. Business analysts on today’s global projects have learned that the standard eight-hour work day doesn’t exist. If we are truly customer-focused and interested in building relationships to capture requirements, we schedule meetings at a time convenient to our customers, not to us.

Few meetings on global projects are face-to-face, making the assessment of non-verbal communication nearly impossible. Since most business analysts pay a great deal of attention to non-verbals as part of the elicitation process, not being able to see them diminishes the communication and therefore the ability to capture requirements. Finally, although there are alternatives to face-to-face meetings, neither video conferencing nor “net” meetings is ideal. Video conferences usually lack some spontaneity and the audio lag can be distracting. Facilitating large groups over a video conference is quite challenging, since multiple conversations, dominance of one group or individual, and other facilitation difficulties abound. With both video-conferencing and net meetings, there are often equipment issues which hinder the requirements elicitation.

Roles and Responsibilities

Unclear roles and responsibilities can be the bane of project mangers and business analysts everywhere. When they are unclear, tasks invariably fall through the cracks and finger-pointing ensues. Unfortunately when stakeholders are removed from each other, it takes longer to find omissions and the resulting errors are harder to correct. Trouble usually occurs if a business analyst expects the business client to define the requirements, but the business client thinks they have already provided the solution and the rest is up to the business analyst. With differing cultural attitudes towards conflict, it can take even longer to perceive that there is a difference of opinion, let alone resolve it.

Language

Language barriers across cultures are numerous. The difficulties caused by differences in languages and even pronunciation among the stakeholders is well-known. In addition, most people have different levels of understanding and expressing both written and oral languages that are not in their tongue. For example, some people can understand another language when spoken, but have difficulty writing it. Others can understand better than they speak and write better than they understand. In order to elicit the requirements, project managers and business analysts need to work with business customers whose language differs from theirs to assess the comfort with both written and oral communications.

Finally, we need to consider the use of TLAs (three-letter acronyms), humor, euphemisms (powder room, passed away, downsizing), and sports analogies (ballpark estimate, coming out of left field, long shot) that can cause confusion and misunderstanding.

The Cultural Landscape

Another barrier is assuming that all team members, whether or not they are collocated, approach the project with the same cultural perspective. For example, I was managing a project that included a male team member who appeared uncomfortable taking direction from a woman. The more I discussed the importance of meeting deadlines, communicating status, and teamwork, the more uncommunicative and uncooperative he became. Finally I realized that the real problem was that I had done nothing to build trust and a strong relationship with him. His cultural work ethic dictated the importance of relationships. Therefore, he completed tasks because of the relationship, not because tasks appeared on a work breakdown structure.

Tips and Techniques for Making it Work

As organizations take on more global projects or projects that include a diverse set of business customers, they need to establish a corporate mindset of acceptance, inclusion, and learning that crosses borders. In addition, the project team needs to understand its inter-dependency in order to have project success. Synergy between the business customers and the project manager or business analyst is required to ensure that the end product is successful. Therefore, each party, the project manager, business analyst, sponsor, and all the business customers have an obligation and a stake in making this cultural diversity work. Without the project manager, the organization will spend more time and money on failed projects. Without the business analyst, the end product will not be usable. Without strong sponsorship and actively engaged business clients, the true requirements will not be discovered, and the end product will not be viable.

Although each party has its responsibility for making the project and end product successful, there are some things that the project manager and business analyst can do that help bridge the cultural gap.

Build Relationships and Trust

Building relationships and trust is important on all projects. There are a myriad of ways business customers can sabotage a project if they are afraid that the end result will jeopardize or dramatically change their jobs, or when the local requirements are not taken into account. With good relationships, issues surface more easily and can be resolved quicker.

The different requirements elicitation venues promote team-building to a greater or lesser degree.

For example, the use of surveys does little to promote mutual understanding.
Facilitated sessions (which may have to be net meetings on global projects) can help build teamwork, but it could take weeks or months for a virtual team to solidify.
One-on-ones serve to build relationships and help navigate the political and cultural landscape. By meeting individually, the project manager or business analyst can assess commitment to the project, discuss individual concerns, gather requirements from those who may not speak up in meetings, and gather requirements related to local needs of the global business experts. One-on-ones can also more easily promote understanding of team members from various cultural backgrounds, because language differences are the least problematic and personal stories and experiences can be more easily shared.

Define Roles and Responsibilities Using a Matrix

One technique that can aid in avoiding the pitfalls of unclear roles and responsibilities is to document them using some form of matrix, such as the Responsibility Assignment Matrix or the RACI chart. These tools use minimal text, so they are easier to understand than textual descriptions. In addition, in order to complete them, valuable discussion needs to occur. By facilitating this discussion, the project manager can help ensure that the fine distinctions between such things as a role and responsibility can be cleared up earlier rather than later in the project.

Example RACI Chart

(Responsibility for doing the work, Accountability for decisions, Consult with on the work, Inform that the work has completed)

Task/Phase	R	A	C	I
Project Plan	Martha	Mary	PMO	Team
Requirements List	Martha	Client	Requirements Consultant	Team Client’s Staff
Modeling (Process, Use Case, and Data)	Ying, Susan, David	Mary	DBA	Team
User Interface Requirements/Prototyping	Martha, David	Mary	Usability Lab	Team
Programming	Sunil, Shashi	Mary	All BAs	Team
User Acceptance Testing	Martha	Client	Sunil, Shashi

Model the Requirements

One of the best ways to elicit requirements is to use various models to represent the requirements. Models, such as process models, usage models, and prototypes can provide a structure that encourages asking questions to find hidden requirements and more quickly document a complete set of requirements. Models have a number of advantages in general, and for cross-cultural projects in particular:

Models have the advantage of needing few words, so the language issues can be more easily overcome. They also have the advantage of promoting a two-way translation of requirements, from business customer to the model and back to the business customer, again with a great deal of structure and a minimum use of words. Models should be created so that they are clear and for the most part understood and used by the business clients.
Models are the most effective way to avoid having different members of the group have different mental pictures of the requirements. They are, for the most part, culturally independent. They can be created using several of the requirements venues including facilitated sessions, one-on-ones, and observation.
Models can help traverse the cultural landscape because they produce unambiguous requirements. That is, there is little room for misinterpreting them. Regardless of the birth countries of the business customers, business analyst, and team, cultural interpretations of the requirements are minimized by using pictures instead of text.
Finally models can be used whether or not the business customers are local or dispersed. Technology now permits models to be easily shared in-person, by email, with video-conferencing, and with net meetings. Because models can be viewed by all, there is less chance for miscommunication of requirements.

Summary

A large, multi-national U.S.-based pharmaceutical client of ours regularly experiences the challenge of cross-cultural requirements gathering. The following are some anecdotes to summarize a few of the key points in this article.

A conference call with a Tokyo client took twice as long to review a process flow as with domestic clients. The analyst kept asking “is there anything else” because of not wanting to omit something important. (Conclusion: plan for extra time when working cross-culturally.)
A similar group of Japanese clients insist on spending time at the beginning of a project getting to know their IT counterparts. They frequently and repeatedly ask that the IT staff come over to Japan to meet and visit with them. When the groups do meet in person, each meeting ends with a glass of sake to celebrate. (Conclusion: relationships are more important than the work in some cultures than others, even to the extent of delaying work. Projects will be stalled until relationships are established, and trust may be even more difficult to establish.)
A cross-cultural team of American, French, and British clients spent two hours talking about an industry term that the three groups swore had three different meanings. They later discovered the terms were really the same and then had to agree on which one to adopt. (Conclusion: language differences will be a challenge, so take the time to define key terms and record them in a glossary during projects.).
A project manager made an onsite visit to a client from Latin America on a project. The project manager had written in an email that he had found a restaurant to go to, but you had to BYOB. The client was confused and asked when they got together: “who is ‘bee-yob’?” (Conclusion: be careful with and define all acronyms!)

In sum, gathering requirements on a multi-cultural project has numerous challenges. To avoid or lessen the affects of these pitfalls, project managers and business analysts should spend time developing relationships, clarify roles and responsibilities in a chart format to ensure understanding by all, use terms and language carefully, and model the requirements to help ask questions. The ultimate goal is to uncover requirements in a way that is easier for all stakeholders, regardless of their language and culture.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. Over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Attendees immediately learn the retainable real-world skills necessary to produce enduring results. Between them they have presented workshops, seminars, and training classes on three different continents to over 15,000 attendees. Their speaking history includes repeat appearances at Project Management Institute (PMI®) North American, European, and Asia-Pacific Congresses, and at Business Analyst World conferences around North America. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP®) through the International Institute of Business Analysis (IIBA®) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK®). They are also certified Project Management Professionals (PMP®) and are contributors of the section on collecting requirements in the upcoming 4th edition of the Project Management Body of Knowledge (PMBOK®).

Requirements ATTACK!

Written by Keith Ellis on August 11, 2009. Posted in Articles.

In my job, I get to hang out with a lot of very senior people and talk with them about requirements and business analysts. The one complaint I hear over and over: “Our BAs are not proactive”. Maybe some in the organization are being a bit passive, but the executives I talk with are most concerned that the BAs are order takers, rather than being seen by the business as really driving the process. You need to ATTACK requirements. Be proactive! And, know the right questions to ask to motivate stakeholders to get you the right kinds of information. Here’s the problem – many analysts get in the way of their own success.

Remove the Barriers

It’s easy to fall into the role of order taker and think the customer can drive the requirements process; particularly in the face of an assertive executive with a fairly clear vision of what they want. I humbly submit, if you roll-over and become an order taker, you’re dead. The requirements on the project will likely be incomplete with significant functional areas missing, and there is likely to be no consensus between executives in the areas of interdependency. Think value-add! The analyst is the one that needs to fill the gap between what the business can articulate for itself, and what the technology department needs as input for successful development. Get people on board with the idea that there is a gap in content that needs to be filled, and remove both the barriers to participation and the barrier to being proactive. If you show you can add value to articulating business needs, you are taking the bull by the horns and being proactive.

Have a ‘Go To’ Process that Always Works

Analysts get caught up in self-flagellation because they have no personal expertise in the business process they are reviewing. Get over it! You cannot possibly be expert in every process and system in the company. Candidly, it’s a fool’s game to try! Even the SVP operating the division must rely on their experts running the subcomponents of the business, as these in turn rely on their subordinates. How can an analyst portray themselves as more expert in every area of operation of the company than these executives without annoying their stakeholders with their arrogance? The analyst is not there to define optimal business practices for the business. The analyst is there to optimize the process used by business leaders to achieve consensus in their practices. The analyst also knows how to take concepts from high level understanding, to clear, accurate and complete documentation.

Before everyone gets angry at me…you absolutely can be expert at doing requirements and getting executives to consensus without being a business area subject expert. Analysts can absolutely be successful where they have a ‘go-to’ process for eliciting business requirements that is easy for participants, and adds value to their thinking process.

First and foremost you cannot get hung up on problem definition. You can do all the problem definition, analysis of issues and look-back reviews in the world and still have massive problems articulating a solution, especially when dealing with something complex. Watch out for the trap people fall into all the time! You cannot consistently jump from problem to solution so spending too much time on getting better resolution on the problem will not get the business closer to solution.

Situation or problem definition can be insightful, but only in so far as it helps bring clarity to the correct needs, objectives and goals. With a solid understanding of objectives and goals, it is not a large step forward to ask: “To achieve these objectives and goals, how must the business process change?” Discovering, eliciting, and describing the processes that change in response to meeting an objective business is the goal of an analyst. The ability to be a great analyst is to have the right kit bag of techniques to draw on to help the business articulate these changes in a systematic, clear, accurate and complete way.

ATTACK the Detail

There are lots of ways to break down projects into reasonable chunks using scenarios, user stories, use cases, or any number of techniques. These only get the surface information. To be a proactive analyst, you need to attack the detail and ask the questions that proactively pulls this information out of stakeholders. To attack the detail, think SIPOC (SIPOC stands for suppliers, inputs, process, outputs, customers). It’s a concept the six sigma folks hijacked, but it’s a great tool for business analysts when you use it to describe how information moves in the business process:

For the scenario “price an order” (starts with confirm item details, and ends with provide quote to customer) ask SIPOC in this order:

Input: What information do you need to know to be able to price an order so you can provide a quote to a customer?
Process: What do you do with that information?
Output: What typically happens once you’ve priced the order?
Customer: Does anyone else need to know about the priced order?
Supplier: Is all of this information coming from you, or do you need input from someone else?

Uncovering how information needs to move to support the business process and ultimate business objectives motivating change is the detail an analyst needs in order to get clear, accurate and complete business requirements. We’re in information technology remember!

Ponder Points

Here are some closing thoughts to consider – or maybe comment on – as you get back to the daily grind:

As the analyst, YOU are accountable for the process of getting the requirements. If you are accountable for anything, it is to be proactive.
Being proactive doesn’t require you to be an expert at all things business. It does mean knowing techniques that add value and can take you from problem to solution.
There are a lot of blind alleys out there! Be sure to that you select and adopt techniques that accelerate you along the path from problem to solution in incremental steps, rather than requiring you to take giant leaps from problem to solution.

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

Bad-Ass BA Lessons. Part 3.

Written by Rebecca Burgess on August 11, 2009. Posted in Articles.

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 two installments 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
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

Now let’s discuss the last two steps to becoming a Bad-Ass Business Analyst. Buckle up, here we go.

Step 9. Speak truth to power

Here are three ways that business analysts can use their verbal acumen to demonstrate leadership.

#1. Someone has to say what needs to be said
Rarely is it worthwhile embarrassing a person in public, but sometimes it needs to be done.

For example, in a group workshop, staff members are engaged in a productive discussion. Ground rules banning in-room cell phone conversations were agreed to. A manager who is there to lend credence to the proceedings and answer any management type questions that may come up receives a call on his cell phone. Instead of excusing himself, he proceeds to take the call, hunching his back and focusing his gaze on the floor as if averting his eyes from the people around him makes him invisible and inaudible.

Our BA-Meeting Facilitator turns to the manager and politely requests that he turn off the &#@$ing phone. As the manager leaves the room with phone glued to his ear applause erupts in the room.

#2. Children whine. Bad-Ass BAs do not whine.
If a BA wants to be taken seriously, whining is the kiss of death. Bad-Ass BAs present the facts, just the facts, and nothing but the facts, followed by a constructive suggestion for moving forward.

#3. Ask for “Guidance” instead of blaming
When asked by a senior manager what the cause of the delay is, a junior team member gets defensive and starts to whine that the team can’t be held accountable for delays caused by other groups.

“Madam Manager, you are right. Our draft of the BRD is late because all sections should be ready for preliminary review today, and section four is not yet completed. We are collaborating with the infrastructure team, and they needed to get information from the data center operations team, and that team is in a time zone 12 hours ahead of us. We are having difficulty conveying to them the importance of their cooperation. We would appreciate your guidance in how to handle this situation.”

In this context, a request for guidance is an encoded request escalation, e.g., that strong motivation be applied to provide the information. Of course you could say, “Would you please arrange for a fire to be lit under that laggard’s butt?” but that might not reflect well on your powers of self-control.

Step 10. Put on Your “Facilitator Flak Jacket”

Rules of the Road

Start on time, end on time
Be present – turn off or silence cell phones, PDAs, computers
Participate in open, honest dialog without aggression
Only one conversation at a time
Avoid rat holes and rabbit holes
Document decisions and don’t reopen the discussion
Be succinct – anyone can invoke the 10 second rule (requesting the speaker to wrap up in 10 seconds or so)
Silence = consent
New rules can be added at any time (any suggestions?)

Slang: a flak jacket is a form of protective clothing designed to provide protection from shrapnel and other indirect low velocity projectiles.

The BA role is a communications hub, as we said before. We spend a lot of time helping people discuss their needs and concerns while trying to move the effort forward towards a goal. Facilitating a meeting with a group of contentious stakeholders is no fun, but it can be interesting. Ideally your company would provide training in facilitation, negotiation, and conflict management. If that is not available to you, think about a high school coach or a teacher who, while you may not have liked that person, you respected because they were able to keep control of an obnoxious group of teenagers. Channel that person. Remember that you are wearing an invisible flak jacket – take criticism in a constructive manner and adjust your conduct if doing so will yield a better result. The flak jacket will protect you from bleeding out when a particularly unkind criticism is hurled at you.

#1: Set the Agenda
Normally the facilitator sets the meeting agenda. If you realize that the meeting agenda isn’t going to meet your needs, offer the list of items you would like to see on the agenda.

“For our meeting on Thursday, I’d like to see us address the following topics. We have been talking about these issues in several other meetings this week and I think we are ready to make some decisions. Could we have these three topics on the agenda? I think if we put them in this order we’ll be able to make the decisions quickly.”

#2: Good Housekeeping
Start with getting people to agree on how the group meeting will be run.

Verify the “Rules of the Road”
For example, if you are running a brain storming session, you will remind people that all input is good, and comments like “that’s a ridiculous idea” are out of bounds.
Identify and agree upon the decision-making method
Decision-making methods range from unanimity, through consensus, to authoritarian. Should the team choose consensus, make sure there is a common understanding of what this means (usually, “it’s not my first choice, but I’ll support it” or “disagree but commit”) and how ties or stalemates will be broken (possibly by delegating the final decision in this situation to a project or team leader, with the “disagree but commit” agreement in that case).
Explicitly call out the expected results/deliverables/goals of the meeting
At the beginning of the meeting, review the deliverables for that meeting, get agreement that they are complete, and then drive the agenda to complete those deliverables. At the end of the meeting, review the deliverables to make sure they have been met.

#3: Keep people to the schedule
“Mr. Senior Architect, I’m sorry to interrupt your story, which I must say is quite interesting. To keep us on schedule, could I ask you to wrap it up in the next two minutes? Thank you.”

There can be a fine line between managing the schedule and permitting the attendees to dig down to unrecognized underlying information. Spread this power around by identifying a rule in the “Rules of the Road” permitting anyone to call a “rat hole” or “rabbit hole” when attendees are either pontificating on something that has already been agreed upon, or are going off topic. Provide a culturally appropriate phrase to use when doing this. Sometimes this can be a nonsense phrase – for example, in a steering committee, one attendee brought a little cut-out human figure his child had made and explained it was named Flat Stanley. Flat Stanley was adopted as the team mascot, and “given” the power to make recommendations to keep the team on schedule. From that point on, the phrase “calling Flat Stanley” meant the speaker should wrap it up and move on.

#4: Manage the conflict
Some of us would rather sink into the floor than be in a room when two people are speaking to each other in a challenging, contentious manner. There’s a certain amount of conflict that is constructive, and even necessary. Shutting constructive conflict down too early is like the game whack-a-mole; it merely means that the conflict will erupt elsewhere. Sometimes we have to bite our tongue and be patient, giving time for the individuals to work it out in a professional manner.

Conflict is not constructive when the argument has been repeated more than twice or when the comments have become personal insults, or people are yelling in anger. At this point the facilitator must shut down the conflict.

“Gentlemen… Gentlemen! Please. Sam, would you record in the minutes that this topic needs to be addressed in a different meeting. Gentlemen, why don’t you two take a five minute break. We’ll move on to item #5 on the agenda.”

This is the third and final installment in this three-part series. Using any of these techniques will make you stand out as an exceptionally motivated and capable Business Analyst. These techniques will develop your sense of intelligent disobedience and increase your ability to act with judicious audacity so use them with care and flare.

You might pick one technique, try it, and be pleasantly surprised at the result. Work your way through the list – all of the techniques take practice to sink in and become automatic. The goal is simply to add techniques to your business analysis toolkit, so experiment and enjoy!

Installment 1 Business Analyst Times June 16/09	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 Business Analyst 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 Business Analyst Times Aug 11/09	Step 9. Speak truth to power
Installment 3 Business Analyst Times Aug 11/09	Step 10. Put on your “Facilitator Flak Jacket”

Don’t forget to post your comments below

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 www.balsamfir.com. She can be reached at [email protected].

For more information on the art and power of facilitation, take a look at “The Art and Power of Facilitation” by Alice Zavala and Kathleen Haas. This book is one of a series in the Business Analysis Essential Library published in 2008 by Management Concepts.

Quick Tips to Improve Your Fact Finding Techniques

Written by Tom Grzesiak on August 4, 2009. Posted in Articles.

In business, we are often asked to draw conclusions and make recommendations. We have to engage in fact finding to ensure that the pieces of information on which we base our conclusions and recommendations are facts, not just speculation, assumptions, or opinions; we have to check any information we obtain. Most of our fact finding will be about how things are done, but it is also important to understand the underlying reason – the why things are done in a certain way – especially during the initial questioning. Our aim is accuracy. We lose credibility if the facts we are using can be challenged by others. This also requires that all evidence be documented in archives for future reference.

There are a number of different methods of fact-finding, and we need to decide which is the most appropriate to achieve the objective. Circumstances may dictate we use a combination of the following methods:

Existing Records include business artifacts, such as organization charts, job descriptions, company reports and accounts, departmental/procedural records, and user manuals. These are appropriate to use when well-established processes are in place and documented.
Written Surveys and Questionnaires can be used to collect information about attitudes and “hard” data from a large group. The advantages of using this method are that they cover a large target population and are reasonably inexpensive. The drawbacks are the low return rate from participants, generally 20 – 50% from random samples, and the need for very careful construction in order to obtain valid information. Of great concern is that participants self-select, meaning that people with strong feelings, either good or bad, will be more likely to respond than people who are indifferent to the topic.
Telephone Surveys are a rapid method of surveying the targeted population. They are more expensive than written surveys, but achieve higher rates of return. These are difficult to use for sensitive or personal topics since respondents will be reluctant to reveal this information.
Direct Observation and Site Visits are very useful at the beginning of a project to get a better understanding of the operations and begin building trust and rapport with the participants. It’s always a good idea to go and see things for ourselves, although this may be expensive.
Interviewing and Discussion require good preparation and a certain amount of skill to be productive. These should be scripted, but allow the interviewer leeway to pursue tangential topics.
Workshops / Focus Groups are an excellent approach to use for brainstorming, envisioning new approaches to a problem, and getting up to speed quickly on new topics. Typically, an interactive workshop contains between 5 and 20 participants and is conducted by an experienced moderator. Focus groups tend to be smaller in size, averaging between 6 and 12 participants. The main differences between the two group-types are workshops tend to be used for internal staff who will break into sub-groups to tackle specific issues, while focus groups are used for customers or external shareholders.
Internet/Virtual Conferencing is used to gather “expert opinion” from around the world. This is typically rapid and makes efficient use of resources, but requires technological infrastructure.
Database Sources such as Dun & Bradstreet, Gartner Group or Standard & Poor’s can offer useful background information that can be reviewed before using one or more of the other fact finding methods.

During fact finding, it is important to pay attention to the non-verbal behavior of the respondent. The use of voice provides additional meaning to the words spoken. For example, a long pause before answering may mean the person is trying to conceal or soften their real attitude. A hesitant “Yes” may really mean “No”. And stock phrases may indicate the person disagrees with you but is unwilling or unable to argue the point.

Observing physical cues also provides information. Restless shifting and tense shoulders often indicate discomfort with a topic, while looking away may mean the answer is not the whole truth. We need to observe the way that words are spoken.

The key skill in interviewing is active listening, meaning we objectively weigh the evidence being presented and pay attention to the non-verbal behavior, as well as the verbal components of communication. We can really demonstrate active listening by reflecting back, paraphrasing and empathy:

Reflecting Back. Words or emotions may be reflected back. An example is: “So, if I’ve got it right you enjoy your work generally, but find working with telecom clients more exciting.”
Paraphrasing. Repeating what the interviewee has said, but use your own words rather than the exact words they used.
Empathy. Listen to the way things are said and, if there is an underlying emotion, we can comment. For example, “You sound a little disappointed with that”, or “You were really animated talking about telecom customers; you seemed quite excited by the opportunities with them.”

Fact finding requires planning and skill. Well done, it provides a solid basis for analysis, drawing insightful conclusions, and making sound and logical recommendations.

Don’t forget to post your comments below

Tom Grzesiak, PMP, is an instructor for Global Knowledge and is the president of Supple Wisdom LLC. Tom has over 20 years of project management and consulting experience with IBM, PricewaterhouseCoopers, and dozens of clients. He has trained thousand of project managers and consultants. Global Knowledge is a worldwide leader in IT and business training. More than 700 courses span foundational and specialized training and certifications. For more information, visit www.globalknowledge.com.