Tag: Best Practices

Do You Measure Up?

Written by Glenn R. Brule on March 8, 2011. Posted in Articles. 1 Comment on Do You Measure Up?

If there’s one aspect of business analysis that bears greater emphasis and attention, it’s measurement. Quantification and measurement are the business analyst’s sure-fire means to show his or her value to the organization as well as the value of the profession. However, BAs often aren’t as diligent or knowledgeable as they should be about measurements.

One of the top requirements management and development (RMD) trends to be on the lookout for this year is greater balance between the BA’s soft skills and technical proficiency with graphical modeling, cost estimates, risk analysis and other measurements. The important thing to remember is that measurements don’t have to be complicated; in many cases a spreadsheet and a calculator will suffice.

Now, let’s look at how to provide measurement procedures and techniques to gauge the value of business analysis as the organization moves from the as-is to the to-be state.

Start With a Three-Pronged Approach

Often the reason BAs don’t adequately measure is because of uncertainty or perceived complexity of measurement requirements. When thinking about measurement, it’s helpful to understand the delineation of the three key areas of the BA’s focus, each of which will demonstrate a close linkage to the others:

Organizational measurement
Process measurement
People/performance/skills measurement.

Organizational measurement looks at business performance to determine whether the BA’s contribution had an impact on success metrics. Measurement is one of the key techniques for charting the course for deconstructing and reconstituting the organization to verify strategic goals are being met.

Consider another of this year’s top RMD trends-the key role RMD will play in organizations regaining market share. The means by which market share can be increased include:

reaching a new demographic
putting a new spin on an existing product
adding, removing or improving on existing services
creating a new efficiency.

At their foundation these goals and objectives have a corresponding financial value which the BA can measure.

At the process level, using songs available from iTunes as a hypothetical example helps illustrate how the BA’s measurement is critical to creating greater efficiencies. Consider, for instance, that the organization states a business need to increase growth by 10 percent. Raising the price of a song from $.99 to $1.29 increases profitability, but doesn’t increase market share. Looking at the variables that address market share, the BA would examine key performance indicators-song sample time, number of clicks it takes to buy a song, promotion and advertising-and measure the impact they have.

Measurement can also be used to determine if an organization has the right people in place with the right skills by identifying areas of competencies and gaps. For example, a business analyst may be a highly effective facilitator of requirements management, but poor at modeling techniques. This disparity in skills sets will obviously impact project efficiencies.

Measuring From the Top Down

Determining measurements for each of these three areas fits within the context of the following “step top down” chart which depicts the focus areas of a project, and also serves as a guide of signposts indicating where measurement, and the opportunity for creating greater efficiencies, should take place.

Take, for example, an organization that determines a business need to become the exclusive provider of Class A widgets. How that will be accomplished is established in goals and objectives, which require creating new efficiencies, whether by developing a new product or service, reducing production time, or increasing production levels, among other options.

The organization’s business policies and rules dictate the manner in which the organization conducts itself, and their impact provides distinct outcomes that can be measured. This measurement provides the opportunity to evaluate whether a rule or policy should be changed.

Measurement at the goods and services level assures that the organization is selling the right products and providing the right support services. This is where measurement can determine questions such as whether enough of a product is being sold or if the product being sold is meeting market demand.

Processes help accomplish the delivery of the organization’s goods and services, and measuring their outcomes are critical to determining whether greater efficiencies can be created.

Tasks and activities are the individual components that are necessary to support the process. Their performance and outcomes can be measured so that changes such as reducing or consolidating steps of a task can shorten delivery or output times.

A favorite exercise that illustrates the concept of measuring throughout project levels is applying business analysis skills and techniques to baking a cake. Starting with a business need to produce a homemade chocolate fudge cake, consider the requirements that go into the final product. What ingredients will be used, where will they be sourced, and where and in what kind of oven will the cake be baked? Where can improvements be made in how the cake is created and in the quality of the final product? Creating greater efficiencies in the various steps to baking a cake requires good measurements that can demonstrate what the BA’s skills contributed to the mix.

The Quick and Dirty Checklist of Measurement Techniques

In A Guide to the Business Analysis Book of Knowledge® (BABOK®), Chapter 9 provides a high level overview of BA techniques, which include useful methods for measurements that BAs should utilize throughout a project or initiative. To avoid getting bogged down and overwhelmed with measurements, one key suggestion to remember is to conduct measurement at a frequency that is acceptable or in alignment with the project complexity. With that in mind, here are the essential BABOK techniques to refer to when gathering measurements:

9.1 Acceptance and Evaluation Criteria

These are the minimal set of requirements necessary for the implementation of a solution and the set of requirements used to choose between multiple potential solutions.

9.2 Benchmarking

Benchmarking measures the results of one organization’s practices against another’s, and compares current outcomes with previous outcomes. Anything pertaining to the organization, processes or people can be benchmarked.

9.8 Decision Analysis

Decision analysis enables the evaluation of different options and is particularly helpful under uncertain circumstances. The BABOK describes particular tools to use to analyze outcomes, uncertainty and tradeoffs.

9.10 Estimation

The eight estimation techniques in the BABOK traditionally have been in the project manager’s toolkit, but they can be applied to business analysis as well. They can help develop a better understanding of the potential costs and effort that an initiative will incur.

9.16 Metrics and Key Performance Indicators

A metric is a quantifiable measure of progress and can be used to measure a Key Performance Indicator, an indicator that shows progress toward a strategic goal or objective. As previously stated, less complexity is preferable with measurement, so whenever possible, select only three to five indicators for metric reporting.

Measuring Will Show the BA’s Value

For BAs, it’s critical to show quantification of the input they have provided and be able to definitively state that business analysis resulted in a five percent increase in profitability or a 10 percent time saving in a process or any other relevant metric of improvement. Though many organizations struggle with what should be measured, these techniques and methods will help demonstrate what the business analyst has contributed. Measurement, after all, is as straightforward as baking a cake.

Don’t forget to leave your comments below.

Glenn R. Brûlé, CBAP, CSM, Executive Director of Global Client Solutions, ESI International, has more than 20 years of business analysis experience. He works directly with clients to build and mature their BA capabilities, drawing from the broad range of ESI learning resources. A recognized expert in the creation and maturity of BA Centers of Excellence, he has helped clients in industry and government agencies across the world. For more information visit http://www.esi-intl.com/.

Rethinking Asking the Stupid Question

Written by Cecilie Hoffman on February 15, 2011. Posted in Articles.

Business Analysts ask questions; that’s what we are paid to do. We are encouraged to be inquisitive, “there are no stupid questions.” We are taught to ask “why” five times to get to the root of the motivation. Most of the time we feel good about asking questions – we’re prepared, we know what topics we want to cover and we know we are talking to the right person. And yet sometimes we realize that no matter how we twist our brain around, what we are hearing doesn’t make sense. It could be as simple as an acronym we haven’t heard before, or as complex as a decision that is so wrong-headed we can’t believe everyone just agreed to it.

What do you do when you have to ask a question you wish you didn’t have to ask? I have seen good business analysts unwittingly shoot themselves in the foot by using this common wishy washy preface.

“This might sound stupid, but…”, or “This might be a stupid question, but …”

Why do we undermine ourselves by prefacing our question or remarks with wishy washy language? The preface says essentially, “I’m insecure about asking this question and I’m expecting you to make me feel bad for asking.” Yes, that’s a harsh assessment – but I’m trying to make a point. You might think that because you are going to interrupt the discussion, the preface is a way of being polite. Is it? Putting the idea into people’s head that you are asking a stupid question nearly guarantees it, which is counterproductive to the importance of your question. Also, you want to save your “stupid” question prefaces for sneak attacks.

There are exceptions to all rules, including the “don’t ever say, “This might sound stupid, but…” rule. In some situations the clever BA will want to launch a sneak attack by asking “crazy as a fox” question, for example, you perceive that people are going along with a line of thought that doesn’t make sense, and you’re about to bring them to their senses with cogent questions that cut to the heart of the matter. In this case, the wishy-washy preface telegraphs to the group that you’re about to pounce. Telegraphing your intent is a viable strategy to get people to pay attention.

We’ll leave the exception aside, and focus on a better approach to asking clarifying questions that require you to interrupt. In general, say what’s on your mind. It reinforces your credibility to present your ideas with confidence. Instead of flogging ourselves with the idea that “I should know this”, try adopting the Generous Listening attitude. What is a generous listening attitude? It’s the view that we Business Analysts are there to hear the essence of the other person is saying, and to it reflect back so they can hear themselves more clearly. It’s not merely replying “So what I hear you saying is …”, and it’s not asking a bunch of questions to further clarify what they are saying so we understand perfectly what they mean. Generous Listening is listening in a frame of mind that helps a person understand what they have conveyed to you and the group.

On the surface, the Generous Listening paradigm’s advice seems contrary to what we business analysts are told to do; Generous Listening advises us to avoid the questions “How?” and “Why?” questions. Before you dismiss this advice, consider creating a space in your toolkit for new questioning strategies. “How” and “Why” are great questions when appropriate, but they can shut down conversation instantly when you’d rather keep the conversation flowing and growing, and when you are interrupting for a clarifying question, usually all you want to do is get your answer, and let the discussion resume. As we BAs know, asking “How?” when a person does not yet know “What” results in mere speculation.

Think about your frame of mind when you listen to a discussion. I know I’m listening for flaws in a person’s reasoning, overlooked cause-and-effect scenarios – my mindset is so tuned for critical analysis that I’ve assumed that there’s something wrong before they finish their sentence! Generous listening is the process of getting at the “what” in the other person’s mind and assuming the “what” is there even if they need help articulating it. The question “Why?” tends to spark defensiveness. Even when appropriate, it may be better to say, “Help me understand your thinking on this … “

Generous Listening recommends adding the following phrases to your toolkit to listen generously and expand a conversation:

That’s a great idea!

Please say more about that.

Interesting! What else?

What would that make possible?

What would that allow for?

Tell me more . . .

What would make that possible?

Help me understand . . .

When we ask questions such as, “What would make that possible?” instead of, “What could go wrong?” an entirely different conversation results. Try it! Incorporating these simple phrases will completely change the character of your communications.

Let’s get back to the short interrupt preface phrases.

Not great: “This may sound stupid but, have we assumed that … “

Do you really need the preface? Here are three alternatives.

Okay: “It sounds like we have assumed that …, is that correct?”

Direct, but could put the person on the defensive: “Why have we assumed that …”

Better: “Would you say more about … , it seems that we have assumed that …”

Here are three additional phrases to use for a quick interrupt:

“I just want to make sure I understand, “DR” in this conversation means “disaster recovery, right?”

“Let me repeat what I just heard, you tell me if I got it right. …”

“Could I just verify what I’m recording for the meeting minutes / for my notes … “

Tips for asking a question that you wish you did not have to ask:

Keep it simple. Eliminate the preface, eliminate add-on questions. Phrase the question in words that the group will understand. By keeping questions simple, you avoid inadvertently inserting distractions into the discussion.

When we say “DR” here, are we talking about disaster recovery or a data repository or dead reckoning?”

The form of this question is “A, B or C?” The simplest form of the question is, “A?” Ideally someone will say, “disaster recovery”, you say, “Thanks” and the discussion continues smoothly. Alternatively, if you ask, “A or B”, someone might remember an issue related to the data repository and the discussion will veer off in that direction, leaving loose ends on the disaster recovery topic. Including the ludicrous possibility of dead reckoning adds a touch of humor which could be useful if you are trying to diffuse a tension-laden meeting, but it distracts people from the topic so use that gambit only when needed.

Be relaxed. When asking a question you wish you didn’t have to ask, don’t make it worse for yourself by telegraphing your unease. Be relaxed, when you ask your question, wait for the answer, then let the discussion carry on. When you are nervous you will increase the anxiety level of the people around you, whether or not they are consciously aware of your discomfort.

Asking questions is our job! When building trust and a shared consensus of reality, making assumptions is the kiss of death. Asking questions, even a question that you are sure everyone knows the answer to except for you, shows that you are paying attention and striving for a solid understanding. Interrupting for clarification can be done without disrupting the flow of discussion and without undermining ourselves.

Don’t forget to leave your comments below.

Cecilie Hoffman’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 authored the 2009 Bad Ass BA series for BA Times and most recently the poem, A is for Analysis. See her blog on her personal passion, motorcycle riding, at http://www.balsamfir.com/. [email protected].

How a Business Analyst Should Prioritize Knowledge Transfer

Written by Kupe Kupersmith on February 1, 2011. Posted in Articles. 1 Comment on How a Business Analyst Should Prioritize Knowledge Transfer

My friend and fellow author on BA Times, the Bad Ass BA, just wrote an article, The Bad Ass BA Observes the Hunt for the Right Business Analyst. In the article she discusses different types of business analysis job requisitions that are currently on all the job boards. One type that she highlighted got me thinking about an issue which companies deal with every day. The type of job requisition she touched on was the “clone the 25-year veteran who just retired” job opening. This is where a hiring manager wants to have someone with the exact experience and knowledge of someone that has been working on the same application and with the same customers for years.

Why do some hiring managers need that? They have relied on that one person to work on that application and with the customer base far too long. Why do they do that? A big reason is that the customer gets comfortable with a particular individual and they do not like change. So as long as the person they love does not want to pursue other opportunities they will stay there until they leave the company due to a staff reduction or reach retirement age.

This particular post will not address the ways a BA manager can help spread the knowledge to avoid this situation. An earlier blog post, The Sadness of the Silo’d BA, touched on this subject. This post will focus on what the new BA who is replacing the long established BA should focus on to be most effective. Until organizations start pairing BAs, BAs will be in silos and will continue to be the only ones with certain knowledge. Coming onto a new project team, a Business Analyst needs to obtain as much information from the departing BA as possible. If you are the incoming BA there is so much information you need that it often feels like you are drinking from a fire hose. You have limited time with the outgoing BA, so you have to prioritize the topics you cover.

Conventional wisdom may lead you to believe the main priority should be the application(s). That in fact should be the lowest priority. Yes, you need to learn the features of the application and as much about the application as possible, especially if you are also responsible for production support. But there are other team members that often have knowledge about the application. QA Analysts and developers have in-depth knowledge of the application, so use them for support until you have had time to get caught up on the application.

Your top priority should be focusing on the stakeholder(s) who may be most upset about a new BA coming onto the project. Have the departing BA schedule time with those stakeholders to personally introduce you one-on-one. It is in your best interest to make these stakeholders feel comfortable. Ask them what you can do to make the transition easiest on them. The reality is that the departing BA is departing. The stakeholder may be upset, but if you ask for their input on making the transition smooth you are taking the first step in winning them over.

Next, get the departing BA to give you a brain dump on how all the stakeholders like to communicate. Which ones like formal meetings and which ones prefer hallway conversations? Get a list of those that like formal documentation and those that do not require formality. Understand what communication medium the stakeholders prefer; email, text, phone, face to face, etc. What stakeholders are usually positive on projects, which ones bring conflict? Are there stakeholders that don’t get along? Are there stakeholders that dominate meetings? I think you get the gist of where I am going.

The BA who is departing understands and subconsciously considers all these factors when interacting with each individual stakeholder. That’s why they love him/her. Since it has become second nature for the departing BA, it may not be easy for them to think of the answers to your questions.

The easier thing for the departing BA is to give you a demo of the application. Fight the urge to allow that to happen unless you have the time – after the analysis of the stakeholder(s) has been completed.

My one warning on the subject is to validate what you have been told. We all have biases and the departing BA may bring theirs when answering these questions. Take into consideration what you have been told – but make your own final judgment as you interact with these individuals.

All the best,

Kupe

Don’t forget to leave your comments below.

How to Handle Tight Deadlines as a Business Analyst

Written by Sergey Korban on November 30, 2010. Posted in Articles.

When you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking – I know this from experience. It’s like driving a racing car – you have to push close to the limits but any error can throw you completely off the track.

The first thing that I do when I get a project like that is considering the reasons for the deadline. You can end up with a tight deadline for a variety of reasons. The deadline may be mandated by the management. It can be determined by interdependencies between projects. It can be defined by market compliance rules. In other cases it’s estimated using the work breakdown structure for the project but ends up being too short because of wrong assumptions.

So how can you as a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully? Keep in mind that sometimes you can be successful even if you don’t meet the original deadline!

Here is a visual summary of deadline causes and ways of handling them:

Let’s look into the ways of handling deadlines in more detail.

Manage the Manager

Management sometimes sets up deadlines with a good “buffer” to allow themselves time for decision making at the end of the project, or because they don’t expect to get results on time and want to push things along by moving the deadline forward. This can be best mitigated by having good communication with the management.

However, what can you do if your manager does set an unreasonably short deadline? Find the tolerance level of your project sponsor (management) and of the key stakeholders who can influence the sponsor. Talk to end users to understand the severity of not delivering on time. There can be scope for negotiation.

Shuffle Dependencies

If your deadline is constrained by dependencies, you can talk to project managers of the upstream and downstream projects to get a better understanding of the interconnections. You might be able to find a way to reorganise things and either get what your project needs delivered earlier, or move the deadline for your own project.

Be Smart About Compliance Deadlines

If you’re working on a compliance project, it may have a firm deadline established by the market bodies. In this case find out if there is a transition period. It is usually provided because market participants have differing levels of compliance and don’t have the same resources available to make the transition. You can also evaluate the impact of breaching the deadline (such as fines for non-compliance), and prioritise the parts of the project which would have the highest financial impact if they are overdue.

Double Check Estimates

When it comes to deadlines defined by estimation, it’s a good idea to double check the estimates. Ask what facts and assumptions were taken into account when the task was initially estimated.

Watch Out For Changes

Once the project starts, you have to watch out for changes in the project environment. Changes will affect project completion time, so work with the team and stakeholders to update the WBS and the schedule.

Organising Work On Projects with Fixed Deadlines

After you’ve applied the practices above and you are sure that you’ve done everything you can to negotiate a reasonable deadline for your project, the next phase is organising your work in the best possible way to meet the deadline.

I’ve found that the following practices help me complete projects on time:

Determine the business context which will be affected by the change to status quo
Define the scope of the solution required to satisfy the identified business need
Plan short iterations to verify the project direction
Align the solution with the existing business processes and IT infrastructure

Each of these practices is discussed in more detail below.

Determine Business Context

Completing this step successfully often determines the success or failure of the project.

Many organizations that operate in a competitive environment have well defined and standardized processes. Many others don’t however, so be prepared to discover them. Explore the business processes which may be affected by the new solution. Learn which systems are used by the business within these processes. Embedding new solutions into these business landscapes should be considered thoroughly to reduce resistance to changes and exclude redundancy in project management, solution delivery and transition to the new state. If done right, it also gives a business analyst an opportunity to find ways to add value to the business.

The rationale for the project should be identified by the project manager, while the business analyst should identify business drivers and actual business needs.

Define Solution Scope

This is the exciting part of the project, but defining solution scope has never been an easy task. Short timeframes and technological changes which may occur during your project make it even more challenging.

In general, to cope with this task the project team needs a solid foundation to build on – well documented processes and good infrastructure. Knowing and using best industry practices can often point you towards defining a sustainable solution and save exploration and research time.

When it comes to defining solution scope, my approach is to use only the “must” requirements for the “initial” solution, and prioritise the remaining “should” requirements into subsequent phased releases (“final” solution).

You must work closely with the solution architect and play an active role in exploring available options. Often the overlap between business analysis and system architecture saves a lot of time – I have saved up to a third of project time by ensuring that the architect could use my documents as a useful starting point in producing a detailed design of the solution.

Plan Short Iterations

I’m still on the fence with regards to the Agile method. Its value is clear in software development (at least for certain kinds of projects) but when it comes to business analysis, I’m not so sure. However, short iterations are one useful technique in Agile which can reduce project time. Use them to get a summary of the completed and outstanding tasks, evaluate changes to the project scope, and identify feasible shortcuts.

Project manager and business analyst need to present a unified front in dealing with business stakeholders. Face to face communication is essential to make short iterations work for analysing the current situation, required changes and making decisions on the next steps. Informal communication style helps too – really, there’s just no time for strict formalities if you want to get things done. It’s very important for the project manager to arrange a “green corridor” for access to authorities and clear the way for the team to focus on delivering rather than struggling with bureaucracy.

As a business analyst, you also have to do your share to deliver results quickly by being professional and active in all your activities (industry research, compliance requirements and so on). Make sure that communication is well maintained between everyone involved in the project.

Align Business and IT Infrastructure

Most of the time new solutions are embedded into the existing environment. It’s a good idea to make maximum use of the existing components and processes to make the introduction of the new solution less intrusive and to minimise the number of temporary patches and business interruptions.

I try to present the solution in terms of interacting services to achieve this. I transform business references to applications and systems into services and show how they could interact. This approach allows me to show the business users how all pieces of the business, including external parties and outsourced services, come together and how the new solution will improve overall efficiency.

Conclusion

Whenever you get a project with a short deadline, don’t forget that there are two major considerations: what can be done to change the deadline, and what is the best way to organise your work to meet the deadline.

The practices presented in this article should help you address each of these considerations.

Don’t Forget to Leave Your Comments Below

Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of innovative visual learning resources for business analysts. We think business analysis should be easy to learn! We deliver practical knowledge visually, with a minimum of text, because that’s an efficient way to learn. Find out more at http://aoteastudios.com

The Bad Ass BA Returns in Didactic Pentameter

Written by Cecilie Hoffman on November 9, 2010. Posted in Articles. 1 Comment on The Bad Ass BA Returns in Didactic Pentameter

The first annual IIBA conference, was conducted in Alexandria, Virginia in October 2010, entitled Building Business Capability (BBC). The conference was a collaboration between the Rules Forum, the Business Forum and the Analysis Forum (the IIBA). A collaboration – how perfect for a business analysis conference. Attendees were encouraged to visit talks in all three tracks and I feasted! I came to this conference in need of perspective, validation, encouragement, enthusiasm and vision, and came away with all that and more. For me it felt like someone had opened up a fire hydrant and unleashed a high pressure stream of quotable phrases and ideas.

The poem below is a distillation of the business analysis track of the conference. My apologies to people who are skillful in this art of iambic and dactylic meters (da dah vs. da dah dah). Read the poem out loud for the best result.

A is for Analysis

A is for analysis – differentiate and abstract,
yields requirements and rules from science inexact.

B is for business, whose capability we improve.
Maximize throughput? Just a step in our groove.

C is for change, for better for worse,

D is for decisions, or leaderless we curse.

E is for elicit, requirements fall not from trees!

F is for functional, remember non-functional, please.

G is for goals, stakeholders have their own,
non-overlapping, we lament and bemoan.

H is for how, counterpart of what,
a distinction so simple yet a knot hard to cut.

I is for iterative, cyclic nature pervades all,
yet management grips tightly to venerable waterfall.

J is our judgment project managers fear,
twin loyalties to business and to projects dear.

K is for knowledge we continuously accrue,

L is for listening which we actively do.

M is for metric, the chestnut is true,
that which we measure can be improved, can you?

N is for negotiate, can everyone agree?
Cross-functional monkey rodeo, that’s no way to be.

O is final outcome, our striving to delight
the blessed product champion who was our guiding light.

P is for process leaving nothing undone,
identifying hidden handoffs, one by one.

Q is for questions we have license to ask.
Assail those assumptions, take them to task!

R is for requirements, our stock in trade.
Oft mistaken for specification, please hand me a blade.

S is for scope, that game of ping pong,
one stakeholder to go,will the decision last long?

T is for trust, partner of integrity.
Armed with the pair, analysis proceeds intrepidly.

U is for users whose lives we make better,
improving usability or efficiency unfetter.

V is for validate and verify, they are different you know,
but it’s value, true value that analysis shows.

W is for who, what, when, why and where, the pentagonal key
that unlocks preconception setting ideas free.

X is for executive whose sponsorship we seek,
facilitating these folks is not for the meek.

Y is for yes, magic word of approval.
Can it be heard without a tribunal?

Z is for zilch, either missing or unknown,
the truth will emerge once the seeds have been sown.

* * *

But what about all the other words I could have chosen? I’m so glad you asked! Here’s the lexicon I started with; I challenge all of you to write your own poem and have fun! I would love to see what you come up with.

A agility, action, automate, analysis

B business

C constraint, committee, consistent, compliance, communication, change

D data, deliverable, decision

E efficient, effective, elicit

F functional, non-functional, facilitate

G governance, gathering, goal

H how

I issue, IT, impact, implement, initiative, influence, iterative

J judgment

K knowledge

L list, leverage, listen

M manage, methodology, metric, missing, measure

N negotiate

O operations, objective, organization, outcome

P production, project, product, process

Q quality, questions

R risk, rule, research, record, ROI, relationship, requirement

S success, structure, support, SME, sign-off, supplier, solution, system, specification, scope

T tools, training, terminology, test, TBD, trust

U understanding, use case, unknown, user

V voice of the customer/data/IT, version, vocabulary, verification, validation, visible, value

W work breakdown structure, who-what-when-why-where

X execute, excellence, executive (cut me some slack)

Y you, yes

Z zero, zilch

Cecilie Hoffman’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 authored the 2009 Bad Ass BA series for BA Times. See her blog on her personal passion, motorcycle riding, at http://www.balsamfir.com. [email protected].