Tag: Communication

Think Before You Speak

Written by Kupe Kupersmith on March 19, 2013. Posted in Articles. 1 Comment on Think Before You Speak

If you know me at all, you may think this title goes against a lot of what I believe in. I am an improvisation actor, and improv is all about spontaneous responses. So you may make an assumption that I am, for the exact opposite,…not thinking before you speak. The trick with improvisation is there is a lot of preparation that goes into being able to respond spontaneously in an appropriate manner. The preparation allows you to open your mind and react quickly when performing. Thinking does happen. It just happens beforehand, and if necessary you can draw out the response quickly. I bring this up because in my last blog, The iTunes Impact on Requirements Analysis, I apparently had a lapse in judgment. There was a sentence where maybe I did not think fully before I wrote. Perhaps something was not thought through completely. And I definitely was not expecting the reaction I received.

Here is the background. I threw in a comment about an urban legend related to Pink Floyd’s album Dark Side of the Moon. I was using the legend as a small example to explain a point. One reader, knowing a lot about the farce this legend is, basically stopped reading or believing in the message I was trying to convey in the blog. In the comments the reader took time to explain in detail the truth about the legend. I hit a ‘nerve’ with the reader; one I did not intend or expect to hit. In hindsight it was not the best example to use. When I was writing I did not think it was a big deal. It was just a situation that I figured a majority of people would know about. The example was not even the main point of my blog. As a blogger I know my audience at a high level. For the most part, I know the people reading my blogs are in one of two categories. They are interested in business analysis or they are my mother. Besides my mother, I just don’t have the opportunity to know all of you intimately. Because of this it is hard for me to know what things will get each individual hung up to the point where they miss the message being delivered.

You, on the other hand, have it easier. You have the luxury of being able to get to know your stakeholders extremely well. One of the critical steps you need to do and prepare for when speaking to or writing something for others is to know your audience. The reason for knowing your audience is to help you determine the best approach to take in order to meet the objective set for the particular situation. What is the objective of writing an email to someone? Why are you meeting with them? Why are you presenting something to a large group? Is it for informational purposes or do you need the team or individual to take action? Do you need them to make a decision or buy into the message you are delivering?

Whatever the objective, you need to consider what will block someone from listening to your message. Here are a couple of common reasons people stop listening.

Grammar and Spelling

Many people are part of a secret society known as the Grammar and Spelling Correction Society. I think they employ more officers than all the law enforcement agencies around the world. You have probably bumped into one or more of them or you may be an officer. They consistently correct your grammar and point out spelling mistakes. In one-on-one conversations they will interrupt you to correct your word choice. If you are giving a presentation you may not be interrupted, but if they see something incorrect on the presentation slide they will begin to focus on the mistake and will be thinking about the error. This is why I always start off presentations stating that if I use the whiteboard or flip chart I can’t be held accountable for spelling mistakes due to these tools not having a built-in spell-check feature. Another way to guard against this is by employing one of the officers. Have them proof your work and correct the errors. I hope the BA Times staff has read through this blog and made some corrections!

Example Use

Examples and scenarios are a great way to explain a point. It helps people connect the message to a possible situation. The problem arises for some people when they try to think through the example and get caught up in arguing the potential of that example really happening. There has to be a society for these people as well! If they can’t figure out how an example can actually happen, they shut down. When I work with someone that does this I do one of two things. If I have time to prepare I think through my example and make sure it could actually happen in reality, this way the person can connect the dots and get my message.

If I am in an ad hoc conversation with no time to prepare I go overboard stating that this is just an example and I have not thought if it could actually happen. I ask them if they are OK with me going forward knowing that. This helps to stop them from thinking about the reality of the example and keeps them focused on my message.

In both situations, you should see a pattern. I acknowledge the potential scenarios that may block the person from listening. There must be some reason why people stop listening to your messages. Feel free to share with the community in the comments below. Regardless of the reason, you need to understand why someone may stop listening and either acknowledge it or prepare to avoid it.

All the best,

Kupe

Don’t forget to leave your comments below.

A Business Analyst’s Best Friends: The Business Sponsor

Written by Angela Wick on March 12, 2013. Posted in Articles. 1 Comment on A Business Analyst’s Best Friends: The Business Sponsor

Successful BAs are the calm, center point of a complex group of interrelated people, roles, and processes. BAs maximize their value to the organization by ensuring the alignment of stakeholder needs and value.

In order to promote alignment, BAs rely on strong relationships with many friends. BAs need to anticipate their friends’ needs and learn how to influence cooperation.

In January, I set the stage for a monthly series describing the BA’s best friends. This month’s friend is the Business Sponsor.

How does the Business Sponsor benefit from a BA?

To answer this question, consider the Business Sponsor’s primary concern: Will the solution meet the needs of my organization, add value, and make me better off than I am today?

On behalf of the Business Sponsor, the BA protects the vision and the goals the solution is set out to bring. The BA safeguards the connection between the Business Sponsor’s needs and the project team’s solution. Here are a few common BA functions that secure the link between needs and solution:

Needs Analysis: Especially, valuable when the Business Sponsor does not have a clear or accurate vision. The BA may be acting as a consultant or evaluator—assessing the needs of an organization and recommending system and/or process changes. In this case, the BA identifies the needs and works with the sponsor to address the needs to create maximum value.
Traceability: The BA ensures the solution satisfies the requirements and all requirements trace back to a business need.
Change Control: BAs facilitate the change process to ensure that changes align with business needs and maximize value.
Full Life Cycle Participation: BA value is maximized when BAs participate in all phases of the project. The BA protects the project vision by providing context and history when critical issues arise during development, system testing, user testing, and implementation.

What makes a top-notch BA from the Business Sponsor’s perspective?

Business Sponsors are most impressed with BAs that can adjust their communication style, both verbal and written, to their audience. Whether in a meeting, on the phone, via email, or in person; the Business Sponsor likes a BA that is confident, makes their words count, and uses an appropriate level of detail.

Given that different Sponsors seek different information in different formats, how is a BA to know what level of detail the Sponsor wants? I don’t think there is one answer to this, except to do the research to find out. Here are few hints:

Listen and observe. Take cues from the Business Sponsor. Who are his “go-to” managers? How do they present information? When the Business Sponsor presents information what format does he use? Observe body language. What seems to energize the Business Sponsor and what causes frustration, eye rolls, sighs, crossed arms.
Prepare. When meeting with the Business Sponsor, anticipate needs. Who will be in the meeting? What topics will be discussed? What issues might arise? What documentation will you need?
Prioritize. In most cases, direct interaction with the Business Sponsor is limited. When you have the sponsor’s attention, be sure to prioritize your needs so that you get the most important topics out of the way first.
Get visual. A picture says 1000 words! A great diagram can make details easily digestible…even for the Business Sponsor.
Learn how to draw, spontaneously. Most interaction with the Business Sponsor happens when critical issues are escalated. Time is short and you need the sponsor to make a decision. Use simple, spontaneous whiteboard pictures to define the problem and propose solutions.
Master the one-pager. Unless you have a Business Sponsor who loves details, learning how to communicate with a one-page document is critical. The one-pager forces you to focus on the most important information. Status reports, project dashboards, decision sheets, or recommendations are perfect candidates for the one-pager. Use color, pictures, or diagrams when appropriate.

What frustrates a Business Sponsor about the BA role?

Too much information, too often.

Most Business Sponsors do not have time to digest massive amounts of detail. They delegate details to managers or SMEs. Given that, BAs need to know when to engage the Business Sponsor. Here are some common reasons a BA might engage the Business Sponsor:

Understand project and solution vision and goals
To approve final documents.
To present a summary of the technical solution.
To escalate critical issues that may compromise value.

The BA needs to remember to use time with the Business Sponsor wisely. Summarize. Demonstrate buy-in from trusted business managers. See the previous question to guide format and level of detail.

How to say no to a Business Sponsor?

The customer is always right! Assuming the Business Sponsor provides funding for the project, I am not sure a BA would say “no” to a Business Sponsor.

However, the BA is a key source of information. BAs help the Business Sponsor understand the ramification of changes, the impact of decisions, the pros and cons of recommendations.

BAs need to speak up when there are issues, communicate why a new direction is inappropriate, look out for risks, impacts, bottlenecks, and assumptions.
BAs also provide context for decisions—real world scenarios that may highlight the need for change or the need to stay the course.

How to influence a Business Sponsor to get what you need?

In most project environments, a BA needs the following things from the Business Sponsor:

Direction – clear vision, defined scope and prioritization of needs and goals
Decisions – make timely, well-informed decisions
Influence – ability to escalate and resolve issues, build consensus, motivate
SMEs- make appropriate resources available to the project

If any of these are missing, how do you get them?

Determine what motivates the Business Sponsor. Listen, review documentation, or ask. Sometimes success hinges on accuracy, timing, cost, forward progress, visibility, efficiency, innovation, creativity, status quo…
Frame your needs within the sponsor’s definition of success.
a. Example 1: If your sponsor values organizational efficiency, explain how access to the correct SME will ensure that every process will be reviewed and optimized.
b. Example 2:If your sponsor values accuracy, explain how accuracy of the data will be affected if an issue is not resolved before implementation.
Determine the proper path to communicate your needs. When interacting directly with the Business Sponsor, present accurate information at the appropriate level of detail. If you don’t have direct access to the sponsor, use your influence with the Project Manager or a key SME to get what you need.

How to communicate the value of the BA role to a Business Sponsor?

In most cases, Business Sponsors delegate project details to managers or SMEs. Sponsors only appear when key decisions need to be made. During these decision points, BAs demonstrate their value to the Business Sponsor.

BA value shines brightest during project transitions when issues arise with potential to impact timelines and budgets. Decisions need to be made quickly and BAs provide the information needed to make a good decision.

As requirements are wrapping up, as UAT ends, during the “go/no go” implementation decision, BAs need to be prepared to speak up.

BAs see the big picture. They understand the impact of potential decisions and communicate the risks and benefits. Asking relevant questions and providing clear, concise information. Often the Business Sponsors are engaged and present and these critical times and this is the perfect stage to demonstrate your value.

What do you think?

BAs: How do you find out what level of detail your sponsor needs?
Business Sponsors: What are the key pieces of information you need from the BAs assigned to your projects?

Don’t forget to leave your comments below.

Ignoring Complexity is Not Simplicity

Written by Hari Shankar on February 19, 2013. Posted in Articles.

Simplify. This seems to be the buzzword in the projects.

Business owners demand it. Project Managers utter it. Architects revere it. Unfortunately IT seldom delivers it.

How can Business Analysts contribute to the goal of simplification? Let us begin with the definition.

What is Simplifying?

Simplifying tends to get misunderstood. Project Managers and Business Owners often treat it at a superficial level. Business Analysts are encouraged by project stakeholders to ignore complexities and focus on simplistic situations. Simplifying is not about being reducing capability. It is about delivering more by choosing smart solutions.

“Very often, people confuse simple with simplistic. The nuance is lost on most.” Clement Mok

For instance, if there is a significant data integrity issue in a project striving for automation, the issue of data purification and reconciliation is often ignored. While the automation functionality may be delivered (often at a high cost), automation ratios continue to suffer.

Simplifying, in the actual sense, involves taking a complex process and re-engineering them to manageable entity. It requires delving deep rather than staying superficial. Simplifying necessitates focus on non functional requirements such as: Scalability, performance, reliability, security and inter-operability.

Techniques for Simplifying

“Simplicity is the ultimate sophistication.” Leonardo da Vinci

Some of the problem solving techniques that can be applied in various business analysis competencies are highlighted below:

Systems Thinking

One of the common problem-solving approaches, useful especially in the initial stage of the project, is to understand the eco-system of the problem domain. As part of enterprise analysis a holistic view of the components of the domain and their interactions needs to be mapped. Context diagram is a handy tool in documenting the results of the systems thinking. System thinking helps to simplify by focusing on:

• Interdependencies (cause effect modelling)
• Goal alignment (ensuring all value streams work towards achieving common goals)
• Convergence (removing redundancies and improving system performance as whole).

Process Patterns

At a business analysis level, identification of process patterns helps to standardize and improve consistency. All business domains over a period of time tend to exhibit entropy. Identifying the essential process patterns helps in implementing control mechanisms that will reduce process deviations.

For instance a campaign management process, irrespective of the channels that is used (direct marketing, phone, internet etc) would have a process pattern like:

Identify target market, contact target customer, promote concept\educate customer, provide offers and initiate fulfilment.

Process patterns help to maintain consistency, minimize and reuse design and improve throughput. It engenders focus and removes activities that do not contribute to the goal of the process.

Think Data

Data elements are the fundamental building blocks in any system. They tend to get more complicated and maintenance intensive, causing data attrition. In a study done by IBM, data quality even in best maintained system has an attrition value of 2%..

Business analysts can simplify the way in which data structures are defined, maintained, displayed to the users. Identifying core and meta-data relevant to business is an integral part of requirements analysis. Naming standards help reducing the profusion of multiple terminologies.

Organizing data structures smartly ensures that business processes operating to maintain the data can be simplified.

For instance, in a telco domain, if the fulfilment process does not define data structures for service level agreements consistently, service assurance processes will suffer.

And Finally

Business Analysts can gain significant benefits by simplifying the way requirements are documented and communicated.

Using relevant diagrams, requirements management workflow tools, modelling data analysis and presenting them innovatively to stakeholders is a critical component of business analysis.

User stories, scenarios and narrative techniques can help the reader to engage and understand requirements better.

Taking a leaf out of Ernest Hemmingway’s book might perhaps help: “My aim is to put down on paper what I see and what I feel in the best and simplest way.”

Don’t forget to leave your comments below.

The Business Analyst as Therapist

Written by Steve Blais on December 18, 2012. Posted in Articles. 1 Comment on The Business Analyst as Therapist

One of the common roles in which a business analyst is cast is that of the go-between. This go-between may be disguised as a bridge (between the business community and the IT project team), a translator (to decipher the business and technical jargon both sides tend to throw at each other), or a referee (whistle and flag optional).

Blaming the traditional lack of communication between the “nerds” and the “suits” on jargon or lack of understanding ignores some basic cognitive differences between the two groups.

Developers who are untrained in psychology or cognitive behavior often miss the psychological factor in their relationships with the business community. That is why the intervention of a business analyst is helpful, if not necessary, to connect the two. It isn’t really in the terminology that each “side” uses, which is the basis for management depicting a business analyst as a “translator.” Learning different terms for things is not difficult if a person wants to do it. For example, I think it’s important for developers to take the time to learn the business they are writing software for. However, there are some who disdain the business and anything else that is not rationally based on a binary system of evaluation.

Even if the developers learn business-speak, as should be the case in agile, according to the adherents, there is still the issue of understanding cognitive biases, emotional influences and irrational human behavior. Simply, people do not always decide or act rationally. Their actions and reactions are governed as much by emotion as by reason. Daniel Kahneman, a Nobel Prize winner, calls this fast and slow thinking. Fast thinking is our default, knee-jerk, emotional reaction, and it is governed by the amygdala. Meanwhile, slow thinking is the rational, reasonable thinking that takes place in the frontal cortex.

Those who spend their careers, and in some cases lives, dealing with the absolute rationality of digital bits and unemotional computers (I am one of those) may not be able to make the leap into irrational human thinking. Computers don’t provide physical cues as to their thinking, so a technologist may not pick up the true meaning in something that’s said that anyone else would understand inherently. The developer is just looking to find out what is necessary to write code. The rest is noise. And there is nothing wrong with that. The issue is that business people do not think or operate at that level. Business people deal in ambiguities and feelings, and are not used to reducing things into binary equivalents. Business people like “may” and “depends” and abstracts while a technologist prefers “must” and “only” and concretes. It is more than just the language. It is really about the concepts, ambiguities, relationships and psychology.

When dealing with the dissonance between the user community and the IT solution team, a business analyst has to be well aware of psychological differences and not blindly focus on the facts. For example, business stakeholders may have a number of unstated expectations about the solution that live on throughout the project and only surface near the end when they see the final product in operation. That is when you hear “Well, this meets the requirements, but it is not what I want.” The developers have issues with this reaction, as well they should. When business stakeholders are broached with the question, “Why didn’t you tell us about this?” the stakeholders respond, “You didn’t ask!” Extracting these unstated expectations from the stakeholders’ heads requires skills usually possessed by psychologists, namely careful and complete elicitation, empathy, understanding and listening.

Business analysts need to have at least a bit of psychologist in their approach to do their job successfully.

The idea of business analyst as psychologist is not far-fetched. Sometimes as a business analyst, you spend a lot of your time just listening, much like a psychiatrist, to complaints, gripes, fears of impending change, protests against impending change, fantasies about how the work should flow or the system should operate, as well as business workers’ problems with IT folks and IT folks’ problems with “stupid users.” There are also problems with managers, management, vendors, off-shore teams and probably co-workers. It is easy for both the BA and the person talking to get a sense of a therapy session. The business analyst is someone who is outside the responder’s business area and who comes in with the express purpose of making a change. And of course psychologists and therapists are all about making changes in a patient. Even though the business analyst is making a change to the organization, that change may affect the responder. Since the business analyst possesses the skills of elicitation, empathy and listening, the responder may open up about more than their idea for a new screen design.

There is also much psychology involved in negotiation, mediation and applying influence, all of which business analysts generally do in the normal course of their work. Each of these communication practices requires the ability to get to the real intent behind the positions, and to identify hidden agendas and deal with them effectively. The intent is often driven by emotional or psychological motives rather than rational business factors. And this is where the business analyst needs to understand human motivation, cognitive biases and emotional stances.

A psychologist or therapist might make a good business analyst, but considering the vast differences in pay scale, perhaps I should say the good business analyst might make a good psychologist or therapist.

Don’t forget to leave your comments below.

Lions and Tigers and Stakeholders…Oh My!

Written by Deena Chadwick on November 27, 2012. Posted in Articles.

If you have ever joined a company or project as “The New BA,” then you know what it was like for Dorothy to follow the Yellow Brick Road.

Scene 1: Kansas
You have either changed companies or changed projects; either way, it usually starts with a maelstrom of new information and expectations (The Twister).

Scene 2: Munchkinland
When you first start on the project, you are usually surrounded by people (Muchkins) who keep telling you how glad they are that you came. Then there is the person you answer to (Glenda); she tells you that you are the person she has been waiting for, that you can fix all her problems. She happily introduces herself and then points you down the path (Yellow Brick Road).

Scene 3: Scarecrow’s Cornfield
As you are getting yourself acclimated with the new project and what is expected of you, you meet a Domain SME (Scarecrow), someone who has a lot of information, but does not have a lot of project or analysis expertise. He knows a lot, but doesn’t know what to do with it. This person can be your best friend, so keep him informed, ask questions, but remember he is not the brain behind the business analysis.

Scene 4: Tin Woodman’s Cottage
You start creating basic work products such as the approach and plan. You have your first few reviews with your stakeholders. At this point you meet someone who won’t budge on her ideas, who can’t seem to play nice with others, and has little or no ability to compromise (The Tin Man). This person can also be your best friend. Find out why she is being so rigid and unmoving, and then grease her wheels. Once you have her on board with your approach, you can use her axe to your advantage. Just remember, when it comes to negotiation and compromise, she usually doesn’t have a heart.

Scene 5: Cowardly Lion’s Wild Forest
You have finally gotten the majority of the stakeholders working toward the same goal and have a few work products that you want to show to the decision makers. At this point you will run into someone who jumps down your throat and tells you that your work is 100% ready for review, that your documents or work isn’t perfect, and that until it is you cannot possibly show it to anyone outside of the team (Cowardly Lion). If you can get past the growl, you will find out that this person is simply afraid that what is being presented will be rejected. Help him to find his backbone and to face his fears. This person probably holds the keys to the castle; remind him that he should be proud to be king.

Scene 6 & 7: Witch’s Castle & Wizard’s Chamber
There is always a point in the project when you think everything is going as planned and you are moments away from achieving your goal. At this point, hidden risks and issues are finally revealed to you. Not because anyone wanted to admit them, but because you finally asked the right questions or pulled back the curtain (Wizard of Oz). This is not a time to get angry or discouraged. At this point the tables turn and those who you looked to for information and guidance now look to you for leadership. Make a plan and mitigate or eliminate the risks and issues (Wicked Witch of the West).

Scene 8: Balloon Ride Home
Now that the risks are all gone (ding-dong the witch is dead), the Cowardly Lion feels like a king, the Scarecrow feels like a genius, and the Tin Man has found his heart. It is time for you to click you heels together and move on to your next project.

Don’t forget to leave your comments below.