As a business analyst, you should know some fundamental skills in your day-to-day work. Many of the skills I’ll discuss in this article you are likely already doing if you’ve found success as a business analyst. All business analysts, regardless of their years of experience, can always use a refresher on the building blocks of effective management, leadership, and analysis.

The skills in this article can be applied in all situations. You can use these skills, techniques, and characteristics to better perform strategy analysis, planning, requirements elicitation and analysis, communication, and even solution evaluation. These are skills that will help you beyond your role as a business analyst, too. Most business analysts play more than one role in their organization, and these are practical skills that can help you in your daily assignments.

Applying Fundamental Business Analysis Skills

It’s becoming clearer every day: the role of the business analyst is more valuable and important today than ever before. Business analysts are more than just requirements gatherers; they conduct gap analysis, write feasibility studies, develop case studies, serve as the hub of communications, and identify problems, solutions, and opportunities. Business analysts are the liaisons for human resources, marketing, sales, and other lines of business and the technology that’s driving the business.

The cost of implementing technology correctly can be expensive and time-consuming. The cost of implementing technology incorrectly can be disastrous to an organization’s bottom line. The business analyst can identify root causes, understand how the solution is to operate, document the problem the stakeholders are experiencing, and then work with experts to identify spot-on solutions.

A well-organized, intelligent, and experienced business analyst can be a valuable asset for any organization. But I don’t need to tell you that. Like most successful experts, a good business analyst understands that his value is not in doing anything fancy. It’s all in the fundamentals. Sure, there’s the occasional magical solution or missing piece of the puzzle—but even those are founded on the basics. To be a superb business analyst, you need to be super at understanding how a business analyst is expected to operate within your organization. Understanding how to fulfill your duties and then doing them well is a sure solution for success, advancement, and leadership.

Follow Us on LinkedIn

Using the Structured Systems Analysis and Design Model

There’s a whole library of structured analysis techniques that a business analyst can use to elicit requirements, to document problems and solutions, and to develop methodologies to uncover opportunities. Structured analysis techniques are developed methodologies to create systems by using a model to identify the problem, to propose solutions, and to design a selected solution. There are several structured models available, and most of them provide a waterfall-approach phasing of the project.

A favored model, the Structured Systems Analysis and Design Model (SSADM) is a classic waterfall methodology, where each phase builds on the work done in the prior phase. SSADM was created in the United Kingdom as a model for developing systems and new applications. SSADM has five components from launch to completion; each component can be broken down into even more detail depending on the needs of the project:

The SSADM Model is a waterfall model that promotes quality.

Feasibility study A feasibility study first examines what the need is, known requirements, and if the organization can cost-effectively deliver on the identified requirements. While the focus of the feasibility study is initially on cost, you’ll likely also have to investigate interoperability with current technology, processes, deadlines, and other known constraints the project would have to operate under.
Requirements analysis The requirements are identified in more detail, and the business analyst documents the business processes, environment, assumptions, and constraints. Technical and quality risks such as quality of service are also documented, as these attributes affect the expectations on performance for the delivered application.
Requirements for specification The functional and non-functional characteristics are documented, and the stakeholders approve the requirements. These requirements map to configuration management within the project management processes, in particular, to scope management. Business analysts could begin to use a Requirements Traceability Matrix at this stage to track deliverables through the execution phase of the project.
Logical system specification Now that the operational requirements have been detailed, the technical systems to create the deliverables are created.
Physical design The program specifications are created based on the logical system specifications. All developers map to the same logical system for uniformity across the solution.

Each phase of the project is done completely in order, and the business analyst and the project manager maintain control over each phase. The phases may not overlap or be created in parallel, for tighter control on the process and deliverables. While this model may take longer to create a deliverable than others, its quality control, phased management, and low defects make it a viable option for high-profile development projects.

Managing Business Analysis Issues

There’s a fine line between risks and issues. Depending on whom you ask, you’ll get different answers for what’s a risk and what’s an issue. Issues are questions, challenges, and problems that may hinder the requirements gathering, project objectives, or identified risks that have yet to be analyzed for their cost, probability, and impact.

A risk is an uncertain event or condition that can have a positive or negative effect on the project. We generally think of risks as characteristics of the project that can harm the deliverables, the ability of the project to complete the work on time, or something dangerous within the project. Risks, however, also include positive characteristics; just doing the project is a risk, as the organization could lose its investment. However, investing in the project could also help the project reach its desired conclusion.

NOTE: quantitative risk analysis examines the probability and impact of each risk in detail. Technically, a risk that has not been evaluated for time and cost impact and for the probability of happening is still an issue.

Risk management is usually handled by the project manager, not the business analyst. The business analyst does, however, need to manage issues. All issues, the things that need to be resolved within the requirements so the project team can go about creating the deliverable, need to be documented in an issue log. The issue log identifies the attributes of each issue, assigns an issue owner, and tracks the status of the issue. The issue owner is the individual who is closest to the issue and may be tasked with resolving the issue. Issues that are not resolved by a given date are likely to become project risks.

During development of the project deliverables, new issues may appear. These new issues could be technical constraints, lagging schedules, or quality problems. Issues can come in all shapes and sizes, but they all have one common characteristic: if they are not resolved, they are likely to have an impact on the project. Issues should always be documented, discussed, and managed.

Relying on Communication Skills

Business analysts are communicators. You’ve got to communicate with the business owner, end users, the project team, project manager, subject matter experts, and loads of other stakeholders. You’ll be talking a bunch. And don’t forget that half of communicating is listening. All of these same people will want to talk to you about their needs, wants, and pet requirements they’ll expect you to work into the project for them.

NOTE: It’s not just what you say, it’s also your body language. Fifty-five percent of communication is nonverbal.

It’s not all talking, however, when it comes to business analysis. You’ll also need to do plenty of writing in your role. You’ll need to document conversations, e-mail threads, the outcomes of meetings, and you’ll obviously need to document the requirements you captured. To be a good business analyst who’s also a good communicator, you first must have a clear understanding of what the project is trying to do. You won’t be able to communicate effectively if you do not understand what people are trying to tell you.

Good communicators, effective communicators, ask loads of questions. You need to understand what people are concerned about. You need to understand what they see as threats—remember, not all of your stakeholders are going to be thrilled with the project and the changes it’ll bring to their lives. Use the classic 5Ws of interviewing stakeholders:

Who is the person and what is their role in the requirements?
What does the person want in the project requirements?
Where is this person in the organization and where will the requirements affect them in their duties?
When do stakeholders need to contribute to the requirements, when will you need to interact with stakeholders, and when can they expect answers to their questions?
Why does the stakeholder have specific concerns, requirements, and direction for the solution? This is often the most important factor to understand about any conversation. Understanding the reason behind any question can help you determine the stakeholders’ motivation, needs, pains, perceived threats, and even their political agendas if they have them.

Communication also means that you’ll make information available for stakeholders. You often won’t have the time to broadcast information, so an internal web site, blog, or even old-fashioned e-mail lists with status updates are ideal. You want to keep stakeholders posted with concise information on what’s happening in the project. While broadcasting information is a fast and wide method of communicating, it may not always be the most appropriate. The message should influence how you communicate with your stakeholders.

NOTE: Remember that larger projects require more detail. The communications formula of N(N – 1)/2, where N represents the number of stakeholders, can help capture the number of communication channels. The more channels you have in a project, the more opportunities you have for communication to fail.

Learning New Skills

One of the most valuable tools for the business analyst, and really for anyone, is the ability to learn new things. Learning can be incredibly hard work, especially in a discipline you’ve never dealt with before. Most IT projects, for instance, are dealing with new technologies. Learning new technology can be a time-consuming activity—especially when it’s a technology that may be replaced or updated in a short time.

There are many different philosophies, methodologies, and approaches to learning. Everyone learns differently. Some people can read a book and learn a new concept. Others can watch someone else do something and then emulate their actions, while others have to get in and try the activity or experience the topic in order to really understand. Chances are you’re like most of us—you learn by doing, but you can also learn from reading, watching, and practicing.

New skills for business analysts often mean attending training sessions. I can confidently tell you three things about learning:

College students often learn in order to get a grade.
Adult students often learn because they have to for their job requirements.
Learners who come through experience courses because they want a new skill.

All of these learners have one thing in common: they have an objective. Whether their learning objective was conscious or not, they all entered the experience with some quantitative object, mission, or goal in mind. Occasionally, I’ve met students who took a class or seminar without an objective—they floundered, were visibly uncomfortable, or left the class never to return. When it comes to learning something new, my advice to you is simple: determine what you need to learn.

I often ask participants in my seminars which is more important, “for me to teach or for you to learn?” The answer should be obvious. While I give my best when I teach, it’s really up to the participants to do their part in the learning process—they need to learn. When I take courses or am coached on a new skill, which I try to do often, I make myself set some learning goals for the course. I determine what specific things I’m going to learn in the class.

Learning is an active process. Learning in a classroom environment is traditionally, in my opinion, a passive process. Students sit like lumps and think about dry cleaning, what’s on television, if the clock is really correct, while the teacher drones on about topic XYZ. Boring! Learning should involve the students by doing, talking, and asking questions. To learn something, get involved with the topic; embrace it.

Defining Your Business Knowledge

To be an effective business analyst, you must understand the company you’re working for. When a new professional business analyst joins an organization, she has a steep learning curve to figure out how the company works, how the company makes its income, and to identify all the channels that decisions move through. Every organization has its documented means of accomplishing tasks, but politics, trade-offs, and oddballs within the organization also can sway decisions.

Beyond the internal mechanisms for accomplishing duties, there’s also the knowledge of what the organization does. If you were to examine any large organization, you’d probably be amazed at all the streams of cash flow both into and out of the company. Larger companies have multiple products, joint ventures, and more to generate revenue. Then there’s the stream of payments to vendors, utilities, taxes, charities, and the constant of salaries. Smaller companies also have complexities that the business analyst must learn and understand to be effective.

Large and small companies have one thing in common: they’re in business to make money. Companies are not in business to provide jobs, to benefit communities, or to solve the world’s problems—they exist for a profit. The primary mission and objective of any for-profit organization is to make money. I’ll agree there are lofty missions, goals, and good deeds that many companies do and do well. I think of medical-related companies, and companies that share the wealth with their employees, but that goodness is still founded on making a profit.

My point in stressing the income of an organization is that the income is directly tied to the performance of the business analyst. Organizations only have so much capital to invest in projects, and projects are founded on the discoveries of the business analyst. Faulty requirements can result in lost funds, lost time, and lost opportunities. These losses can contribute to the decay of the company’s primary objective—to make a profit. Even not-for-profit entities are subject to the negative effect of the business analyst’s performance, as lost funds can hinder them from reaching their missions.

Business analysts must understand what a company’s goal is and the means by which the company aims to reach that goal. Each business analysis activity either contributes to the goal or detracts from it.

Knowing the Products and Processes

Your company produces something. It could be a physical product, like a car, computer software, or light bulbs. Your company might be in the service industry, where you perform activities for others such as renting resources, consulting, or designing web sites. The things and services that your company produces affect the role of the business analyst.

Most organizations follow a logical pattern to create the product that generates income for the company. If you build houses, there’s a logical life cycle of the construction process. If you design software, you likely subscribe to a software model. If you consult, then there’s a logical approach to your consultation. While each project is unique or different, the approach of the project is probably very much the same each time.

Understanding what it is your organization creates for others can help you, the business analyst, elicit requirements, offer solutions, and control the business analysis processes to support the larger vision of the company. This is probably something you already do, because it’s logical. A company that manufactures cars likely won’t have requirements to start creating bicycles. The business analyst should learn as much as possible about the lines of business within an organization so that she can intelligently ask requirements-based questions, identify opportunities, and find the best solutions.

Your organization’s processes were created, by design or by the logic of the inherent nature of the work, to support the creation of the products or services your company provides. Processes are actions that bring about a result. Think of the processes within your company: procurement processes, project initiation processes, quality identification, monitoring and control, and risk management to name a few. Processes are specific activities to achieve, learn, create, or confirm something.

Recognizing a Process Purpose

Just because a process exists, doesn’t mean that it’s a good process. When I serve as a consultant, I like to start with the flow of processes to see how a product moves from concept to creation. It doesn’t matter whether the organization is creating software, designing web sites, or creating pharmaceuticals—processes move the business along. Some processes just don’t provide value, don’t create anything that supports the product, or can’t be explained.

Not all processes contribute. Here’s a story that helps prove my point. A husband and wife were cooking dinner, and the husband noticed his wife cut off the ends of the pot roast they were about to cook. “Why are you cutting off the ends of the roast?” asked the husband.

“I don’t know, really. It’s just what my mom used to always do,” said the wife.

This puzzled the husband, so at his next chance he asked his mother-in-law why she cut the ends off the pot roast. “I don’t know, really. It’s just what my mom used to always do,” said the mother-in-law. Now the husband was more than curious. He wondered if slicing off the ends of the roast improved the taste, helped the roast cook faster, or some other cooking secret.

The husband, wife, and mother all went to visit the grandmother, determined to learn the reason why she cut the ends off the pot roast. “Grandmother,” asked the husband, “can you tell us why you always cut the ends of the pot roast off?”

The grandmother thought for a moment, and then her face lit up. “I always cut the ends off my pot roast because my cooking pan was too small.”

Processes are much the same way. Just because an organization has always done the work a certain way, doesn’t necessarily mean that the processes are good. A business analyst should understand how processes work and then learn why the processes are in place. Processes that can’t be explained either need further exploration, documentation, and detail, or they can be attributed to grandma’s pot roast.

Recognizing Market Conditions

A business analyst should be aware of the market conditions that affect the organization and its decisions on projects, requirements, and opportunities. It’s usually not a secret how well the organization is performing based on the amount of work, opportunities, and growth a company is experiencing. The market conditions affect the short-term and long-term goals of an organization.

Market conditions can describe many different things. First, consider the classical supply and demand scenario of the marketplace. When demand is high and supply is low, you’ll experience an increase in price and profitability. When demand is low and supply is high, prices generally fall. No mystery here, right? Supply and demand affect all businesses, and there are decisions to be made in a saturated marketplace—increase sales or reduce costs?—all of which generally involve the business analyst. Supply and demand can also prompt an organization to look for new opportunities, once again calling on the business analyst for assistance.

Beyond the classical supply and demand, all sorts of economic circumstances are attached to the health of the economy. The ability and willingness of participants in the marketplace to purchase goods and services affect decisions of the organization. The marketplace conditions are beyond the control of the organization—so it’s the external constraints that affect income. The business analyst may get involved in looking for solutions, opportunities, and identifying problems of sales in less-than-desirable economic conditions.

The role of business analyst is also needed when the market is booming, times are good, and money is flowing. The business analyst often is needed in good financial markets to look for opportunities, investments for longevity, and to meet the constant need to cut costs. Removing waste, even in healthy financial times, obviously boosts profits, but also often increases productivity, quality, and ensures continued success for the organization.

Recognizing Organizational Systems

Systems are standardized process sets in an organization that has identified the flow of activities to reach a desired result. Systems are techniques unique to each organization that help its members reach results. Systems ensure that activities are done the same way, in the same order, every time. They establish a framework for common organizational activities to ensure consistency, thoroughness, and documentation.

Common organizational systems include

Human resource management
Procurement management
Quality assurance and improvement
Resource allocation management
Facilities management and maintenance
Project initiation and management
Project change control
Product configuration management

Systems are well-documented and standardized within an organization. The business analyst is to use these systems to move through the proper channels within the company to ensure that the work is done the same way every time. Circumventing a system is likely going to cause the business analyst some grief, may irritate the people that control the system, and could cause delays in the decision the system is to generate.

Systems are part of enterprise environmental factors, because they define the rules and policies for doing certain activities within the organization. The business analyst may define a system, with some caution, as a constraint on the requirements, project, or program. A constraint is anything that limits the project’s options, so a stagnant, non-functional system may restrict the project, but not participating in the system may bring more pain than abiding by the rules. In other words, you have to follow the red tape and bureaucracy of an organization if you want to participate in the organization.

Relying on Expert Judgment

Expert judgment happens when a person relies on someone with more knowledge to help make the right decision. Consultants, subject matter experts, the technical team, and even the end users are all examples of expert judgment. All of these resources are “sources of knowledge,” and it’s up to the business analyst to recruit and employ these sources of knowledge to make the best decisions about the requirements.

Expert judgment, as reliable as it can be, often is tied to a fee. The business analyst should determine if the information the organization will be purchasing is from an experienced, knowledgeable resource and if the fee for that information is worth the information gained. The business analyst should determine what resources are available, the associated costs, and the benefits the costs will bring to the organization. In addition to considering the value of the immediacy of the information, the business analyst should consider the value of the time savings the information can bring to the project.

Expert judgment isn’t always people, however. You can, and should, use historical information as a source of knowledge for your project. Historical information comes from previous projects, project archives, and lessons learned documentation. Every organization, regardless of its size, should have a project information archiving system to organize and store the paper documentation and provide access to project files for future reference. There’s no reason to reinvent the wheel if past information is already proven.

Using past information to make current decisions is a great resource, as long as the past information is accurate. Faulty decisions, project plans that weren’t updated, or deliverables that were poorly documented can haunt new projects based on this documentation. Every decision in a project should have some supporting detail not only to help the current project, but also to provide insights to future project managers and business analysts.

Mapping IT Projects

When a new business analysis effort is started in the IT arena, it’s important to categorize the requirements and interoperability of the solution. It’s important because it can help the business analyst identify resources, affected lines of business, and communication among the stakeholders. IT projects fall into one of four areas:

Applications: Includes software-driven solutions for workstations, servers, mobile devices, and the Internet
Hardware: Includes servers, workstations, laptops, and devices like printers, cameras, and peripherals
Database: Includes database servers, data management, data security, and accessibility
Network: Includes the connectivity and communication among computers, servers, network devices, and telecommunications

These four categories aren’t isolated from one another—they’re often interdependent. Consider an application like e-mail. While the client application operates on a workstation, the e-mail server application is the database of messaging. The network portion includes the local area network, remote networks, and even mobile devices. The interoperability of these four systems requires analysis and consideration of the problems, constraints, and opportunities within all four areas.

Users often interact with several systems without realizing it.

Working as a Business Analyst

If you were to read a job description for a business analyst, you’d probably find requirements for the position such as the ability to identify requirements, work with different lines of business, lead technology assessments to develop business use cases, identify functional requirements, map process flow, and the usual processes you’d expect. But to work as a business analyst is more than these typical job requirements.

Business analysts need to be able to quickly learn, adapt, think logically, and make decisions that can affect the entire organization. The advanced skills of a business analyst aren’t that different from the advanced skills of a team leader or project manager. You’ll need to be able to facilitate meetings, create clear and concise documents, negotiate with stakeholders, and think logically and creatively about the problem, solution, and business opportunities you encounter.

You’ll work with business teams, define life cycles, research problems, identify solutions, perform data analysis, and participate in creating projects that work. Business analysts work with project managers to ensure that projects are meeting the business requirements and that the solutions are cost-effective, efficient, and accurate.

Hosting Effective Meetings

Meetings are actually expensive—and I’m not talking about the donuts, coffee, and soda you might provide for participants. When you invite 15 people to a typical two-hour meeting, you’re really hosting a meeting that’s worth 32 hours of labor. Thirty-two hours? Yep. You’ve 15 people in the meeting plus yourself; add four more people and you’ve one week of time for a two-hour meeting. Requirements meetings can last for days, so you can see why it’s so important for the business analyst to host good meetings that don’t waste time, have set objectives, and actually accomplish something.

This is why you should first determine who really needs to be in the meeting and what their contribution or takeaway from the meeting will be. I’ve sat in more than one meeting, and I’m sure you have too, where I had nothing to contribute, and the only thing I got from the meeting was a donut. As the business analyst, you should first determine who should attend the meeting and then ask some key stakeholders who else should attend and why. You don’t want to waste people’s time, but you also don’t want to overlook stakeholders who should participate.

I’m a huge fan of agendas for any meeting. Agendas should be created and distributed a couple of days before the meeting to get feedback from the participants. Any updates to the agenda should be redistributed so everyone can anticipate what the meeting will accomplish. Whenever possible you should call the meeting attendees to remind them of the meeting and tell them what the meeting will accomplish. This can ensure that participants will attend, remind them to bring the correct information to the meeting, and collect any necessary information you’ll need from the participants before the meeting. It’s also a good idea to distribute the finalized agenda with a meeting notice to remind attendees when the meeting is to happen and what is to be discussed.

There’s often some question about what the meeting agenda should be. It’s simply an organized listing of what the goals of the meeting are. It creates order, boundaries, and a logical approach to the events of the meeting. When you start the meeting, distribute the agenda to the participants who failed to bring the copy you distributed premeeting. I like to quickly introduce the meeting’s objective to match the description I’ve informed people about already. This keeps the objective for the meeting in mind. While an agenda can provide structure, you should allow some flexibility if the participants are accomplishing an objective.

When you start the meeting, on time of course, thank everyone for coming to the meeting to discuss the topic at hand. Review the agenda as you’ve designed it, and get to work quickly. People are busy—jokes, chitchat, and banter are okay for informal sessions, but wasted time can result in a wasted opportunity. I always have written on a poster or white board four simple rules for any meeting. Use them if you like:

Focus: Turn off cell phones, e-mails, and train your brain on our immediate goals.
Participate: We need your input, questions, ideas, and comments. Get involved.
Move: Let’s make decisions and keep the meeting momentum.
Close: We have goals in this meeting. Let’s accomplish and be done.

Part of meeting management is also time management. You need to facilitate the meeting, which means keeping the attendees on track to the agenda. If you have trouble keeping attendees on track or from lingering over conversations, interject, interrupt, and smile. Don’t be condescending, but sometimes attendees don’t realize they’re rambling. One of the ground rules above is to keep the meeting’s momentum; don’t let the meeting stall with war stories and talk over decisions that have already been made.

You should also periodically ask attendees how they’re doing. Ask if they think the meeting is accomplishing its goals and if anyone has any suggestions for the meeting. A postmeeting complaint or suggestion is valuable for the next meeting, but it doesn’t do anything for the current meeting. Be accepting of input from participants, and put suggestions into action if they are good. I recommend you do this quick check of the meeting status every couple of hours and adapt accordingly.

At the end of the meeting you should also ask participants how they felt the meeting went. Verbal reviews of the meeting will usually result in generic approval, so for longer meetings distribute a quick evaluation sheet. This doesn’t have to be fancy, just a five- to ten-question survey on the meeting, with space for comments or suggestions. This can help you improve your meeting management skills and help for future meetings.

When you’re ready to close the meeting quickly, review assignments for participants based on the outcome of the meeting. If you’re hosting a follow-up meeting, remind people of the next meeting and gain their agreement to attend. You should also follow up with participants with a thank you for participating in the meeting and remind them of their assignments as promised. End on a positive note, smile, and let people go.

NOTE: It’s important to thank people for participating in the meeting. Don’t thank people for attending; meetings are work.

Thinking Like a Business Analyst

As a business analyst, you need to think beyond the symptoms and look for causes. You already know through use case studies that you can experience the symptoms. You can also facilitate cause-and-effect meetings and create Ishikawa diagrams to help you identify causal factors. You also need to ask effective questions. Strategic questioning looks for results instead of narratives. You want to ask questions that make people think about the requirements.

Cause-and-effect diagrams are also called fishbone diagrams.

Style your questions to create a partnership with your audience instead of challenging them. For example, here are some good questions to help your stakeholders dig deeper:

How important is this requirement?
Have you experienced this problem or something similar before?
What do you think the problem is?
What do you hope this project will accomplish?
How soon would you like this requirement?
If you could change one thing about your current situation, what would it be?
What would you change next?
Is there anything that you’d like me to ask?

These types of questions are open-ended and help the dialogue along. Based on what the stakeholders say, you can branch into more open-ended questions. Of course you’re documenting their answers, so you can follow up on their input. When interviewing stakeholders, it’s a good idea to check back with them later to see if they’ve thought of anything else you should know. It’s funny how our minds will think of ideas after the meeting, so give stakeholders a second chance to add information.

One approach you may want to consider using is system thinking. This is a philosophy that really contrasts with the traditional decomposition of a symptom, problem, or scope. Usually when business analysts examine a problem, they’ll break down and isolate the problem—which is a fine mode of attack. Systems thinking, however, examines the whole system with the belief that the symptom is a product of the system as a whole. Actions in one component of a system have effects, even subtle effects, on neighboring components. The relationships between system components are studied for effectiveness as much as the processes within the components of the system.

Systems thinking allows for the possibility that an improvement in one area of a system, such as an organization, can have negative effects on other areas of the system. A simple example is a change in the policies for accessing web sites. Blocking access based on key words can actually stop users from accessing legitimate web sites. While the inappropriate content may be blocked, time, effort, and efficiency are hindered on other levels. A broader example is seen in nature with the introduction of the Kudzu plant from Japan as an ornamental plant. The plant is a pretty, lush vine, but it has ravaged parts of the southern United States.

Business analysts also need to think about the culture that their solution may affect. With international projects, the business analyst should understand more than just the language differences, time zones, and holidays. Cultural issues can affect how well the project manager can operate in an international environment. The Sapir-Whorf hypothesis, for example, posits that the language a person speaks affects how the person thinks. It’s an interesting theory created by Edward Sapir and Benjamin Whorf.

The Sapir-Whorf hypothesis is relevant to international business analysis because, if you subscribe to the theory, different language patterns affect understanding and thinking. In this theory, how you think is based on the language you speak; your thoughts may be different and in contrast to how people who speak other languages think. You need to communicate in more detail and strive to confirm a real understanding of what’s being communicated between you and your international stakeholders.

Another international element that can affect your projects is ethnocentrism. Ethnocentrism is when individuals judge the world based on their own culture, usually with the belief that their culture is superior to everyone else’s culture, belief, and ethnicity. Being aware that other people have different values and priorities is a good method to combat ethnocentrism. You do, to a certain extent, have to be an anthropologist to overcome the self-serving beliefs ethnocentrism promotes.

Serving as a Leader

There’s been an awful lot written about leadership. Cruise into your favorite bookstore, and you’ll find rows of books just about leadership. Do an Internet search on leadership, and you’ll be overwhelmed with results. Leadership is something we all crave, many aspire to, and all of us need. Leadership is the alignment, motivation, direction, and inspiration a person can give to others to call them to action. Leadership is inspiring people to take action because they want to, not because they are required to.

Leadership skills can help you in your career, your life, and may be the catalyst for helping people in your organization achieve great things. Organizations have people that you can identify as leaders and people who are definitely followers; leaders need followers, but more importantly, followers need someone to lead them.

People want to be led, but they want to be led by someone they can believe in. To prove themselves, leaders must be willing to do what other people are not. Leaders must be willing to act, to work, to get involved. The best leadership is leading by doing. Nothing commands respect among others more than a leader who’s involved in the work, involved in the accomplishing, and puts forth as much or more effort as everyone else in the project.

Coaching and Motivating Stakeholders

Coaching is when you help another think about the actions they’re required to do in order to achieve the things they want in their life. Coaching is not you doing for someone else, but rather you using activities, conversations, interviews, and exercises to help people realize what it is they want to do in their personal and professional lives and then inspiring those people to take action to accomplish goals.

In a professional organization, coaching is often limited to roles, responsibilities, and skills. A professional coach, sometimes called a life coach, is a person who uses coaching activities to help people think about and take action on changes in their lives. Both professional coaches and organizational coaches need an internal desire to help others reach their full potential.

Much of coaching, in any capacity, uses the same skills you’ve learned to be a business analyst. Coaches ask questions, explore solutions, listen to clients, and elicit requirements about the clients’ ambitions in life. The role of a coach is to help others make decisions and determinations, create plans to achieve, and then act on those plans. Coaching as a business analyst isn’t necessarily needed in every project, but business analysts have opportunities to manage others, work with others, and can serve as a coach when appropriate.

Part of coaching clients is to help them realize their long-term goals. Ambitions, dreams, and “somedays” just don’t work when it comes to creating goals. Goals have specific requirements, achievable results, and deadlines to achieve them. Long-term goals such as an advanced degree, certification, or completing an event can be broken down into smaller, achievable, and traceable goals for each month, quarter, or even year.

Coaching and motivation go together, but motivation, real motivation, has to come from within each person. For example, if I tell you to leave a building even though it’s cold, dark, and rainy outside, you might not want to. Even if I tell you to leave the building in a kind way, and smile, and hold the door open for you, you still may not want to. But if I show you that the building is on fire, now you’re motivated, and you want to take action. Motivation is an internal desire that makes you want to take action.

As a business analyst, you may find sustaining motivation for the business analysis team, the project team, and the involvement of stakeholders is a hard job. You need to first identify what motivates people and use that thing to keep them moving forward. Motivating factors are different for everyone, but common motivational factors include

Fear: Not acting may bring about unwanted results, attention, or punishments.
Ambition: Personal achievement can motivate people to excel if they believe their current actions will help them reach future goals.
Recognition: Sometimes a public recognition, commendation, or mention of their hard work is enough to motivate people. A business analyst should always thank team members, by name, for their contributions.
Rewards: Financial gain, vacation days, or other rewards can motivate people to action.
Avoidance of consequences of inaction: Sometimes inaction may bring about results that the person wants to avoid. Think of health issues, documentation of performance, or financial penalties.
Peer pressure: When a project team, business analysis team, or any other team are all working together, it’s more difficult for individuals not to contribute to their project.
Expectations: When a person is assigned activities to complete from someone they admire and respect, they’ll generally work harder to meet the expectations that have been placed upon them.

Coaching, long-term goal setting, and motivating are all linked together. The most important element of the three, in my opinion, is goal setting. If people are being coached but they can’t see a mental image of their achievements, then coaching is just a nice conversation. Without goals there’s really nothing to be motivated by. Goals are things, accomplishments, and results of hard work, but you need to be able to see exactly what you’re trying to accomplish. Once you know what you want, then your motivation can help you reach that goal. Coaches can help fuel the fire and hold you accountable to taking actions to reach results.

Performing Appraisals

If you’re the business analyst for a large project, you might have a group of business analysts who report to you. If that’s the case, you’re probably going to have to appraise their work and contribution to the project and account for their work on the business analysis duties. Appraisal skills are often handled by functional managers, but an organization can elect to have a business analyst, project manager, and even a team leader review a person’s performance.

If you’re assigned to complete an appraisal of someone’s work, you have responsibility attached to the review. In some organizations appraisals are a joke because they’re rushed, don’t matter to the overall performance review, and people don’t often tell the truth on the appraisal. I’ve seen reviews of team members where every single team member was reviewed identically to every other team member. You don’t need a PhD to see that the reviewer didn’t take the evaluation seriously.

Appraisals—effective appraisals—should be well-designed to capture exactly what each team member contributed to the project. Time and thought should go into the performance appraisal, and the review should reflect exactly what the team member did on the project. This means the business analyst will need good records, time to review what was or was not completed by the individual, and supporting details of the performance.

What many organizations miss is for team members to have an opportunity to appraise their functional manager, business analyst, or project manager as well. If appraisals exist to review performance and to promote better performance, it should be a two-way street. Appraisals should be made of management and not just of team members. Politics and fear of reprisal often stop that from ever happening. Whoever is performing the appraisal should follow six general rules:

Prepare: As I’ve mentioned, it takes time to collect evidence of performance, fact, and supporting detail. Doing an appraisal of someone’s performance without knowing how they actually performed is disrespectful.
Review performance: The appraisal is to review what the person has done, not what was intended to be done. If the person did reach goals and expectations, that’s great; if not, then an explanation is needed. There may be valid reasons why goals weren’t met, and the individual should have the opportunity to explain his position and what he’s contributed.
Listen: As a business analyst this should not be hard for you—you listen a lot. Avoid the temptation to ramble; ask a question and allow the person to speak. Use open-ended questions rather than closed-ended questions (closed-ended questions can end with yes or no; open-ended allow people to converse).
Avoid politics: Politics are a part of every organization, like it or not. The business analyst should take the high road and avoid politics, subterfuge, and reviewing personalities instead of performance.
Be specific: Appraisals are a form to review performance, so you’ll need to cite examples of performance. Exact details of work completeness, schedule, quality, and acceptability are needed as evidence of the person’s good or bad performance.
Set achievable objectives: In business analysis you want to avoid subjective definitions and characteristics such as fast, good, and happy. The same thing is true when it comes to setting objectives for the project. Good performance is too subjective to measure. When it comes to setting goals, you’ll need specific, measurable results for accountability.

Appraisals aren’t just for what the individual has done, but they’re also an opportunity to offer encouragement and feedback on how they can improve their overall performance. Appraisals can be an excellent opportunity to set achievable goals for the team member and point them to milestones that can help them achieve their goals. If goal setting is attached to performance appraisals, the goals should be documented and reviewed with the team member throughout the year to make certain they’re on their way to achieving goals.

Summary

Business analysts can help businesses identify and organize requirements for projects and business opportunities. Business analysts can help identify the most cost-effective approach to reach a solution or seize an opportunity. Business analysts work with other business analysts, the project team, the project manager, business owners, and other stakeholders to identify requirements, control requirements, and ensure that the project deliverables are created according to the demands of the requirements.

One approach to help organize requirements management and creation is the Structured Systems Analysis and Design Model (SSADM). It uses a waterfall approach that tightly controls the work and objectives of each phase before allowing the project to move on to the next phase. All projects in the SSADM model start with a feasibility study to ensure that the project goals are achievable before moving into the requirements analysis phases. The final phase of SSADM is the creation of the physical design.

Business analysts may need to do issue management for their requirements. Remember that issues and risks, while similar, are not the same thing. Issues are questions, challenges, and problems that may challenge the requirements gathering, project objectives, or identified risks that have not yet been analyzed for their cost, probability, and impact. Risks are anything that may affect the project for better or worse, though typically worse, and hinder the project from reaching its objectives. All issues, their condition, ownership, and status should be documented in an issue log.

Communication is another key business analysis skill, as business analysts need to serve as the hub of communication in the project. Effective communication means listening, asking questions, and striving to clearly understand what’s being communicated to you. By understanding the requirements, you can formulate helpful questions and form conversations about what the stakeholder expects from you, the business analyst.

Another skill discussed in this article was understanding your organization’s products and processes. By understanding what your company creates and provides for others, you’re able to see project and portfolio management in light of what’s most important for an organization. The systems within your organization control the flow of data, decisions, and projects that may get selected.

The market conditions that your organization must operate in have a direct correlation to the types of projects, problems, and solutions that you may be called upon to analyze. Understanding your organization and the market that’s affecting its outcomes can help you perform better as a business analyst. Market conditions are more than supply and demand, though it’s often as simple as that. The economy, saturation of competition, and the relevancy of what your company provides can all affect corporate income.