Tag: Stakeholder

Seven Ways to Dramatically Improve Stakeholder Consultations

Written by Alan Kay on July 27, 2010. Posted in Articles. 1 Comment on Seven Ways to Dramatically Improve Stakeholder Consultations

I’ve done many stakeholder consultation projects for a variety of clients. Consultations are an important and growing component of aligning organizations, both public and private, with the community they represent or serve.

The simple, clearest reason for engaging with stakeholders is to make strategic and tactical decisions more effective and efficient. A purposeful engagement can make strategy a powerful tool because it’s about the stakeholder community, not just the service provider.

In the past they have tended to be viewed by some as a necessary encumbrance and, as such, may not have been effectively leveraged. Why? People will naturally tend to express their doubts and concerns when you ask for their opinion in an open forum. For a few, it’s a therapeutic opportunity to express their deep frustration. The voice of frustration tends to dominate and often sounds like that of many. It’s not. I remind you of my favorite line about angry voices; never wrestle with a pig – the pig enjoys the wrestling and you get dirty. When we discuss problems at any length it keeps the person in a state of being stuck. Our interest in their problem means we are not being helpful to them

The bottom line? The old model of taking too many of the complainers seriously simply slows progress. The good news is that progress is being made.

Here’s where I have seen consultations turn into powerful exercises (using Solutions Focus) to align communities and the organizations that have to make things happen.

Be clear on higher outcomes. For example, a recent consultation was designed not only to actively listen to group of stakeholders largely at war among themselves, but also to let them listen to each other for the first time
Pre-planning should involve a core group of the stakeholders to find out what outcomes they’d like to get. Make sure the stakeholder audience will know clearly what your goals are and tell them your point of view
Allow the group a short period in every session to express their concerns, but don’t let a few people dominate. Other than their demands they usually cannot express what they actually want
Better to ask the group what’s working at their level, how they are managing to cope despite the complexity (difficulties) and exceptions to the problem. Don’t skip asking what’s working but make it short – it’s the basis of helping them get unstuck;
Turn to what needs to be different, or better in the future. Find out what the larger group has in common about what needs to get better. Start by asking, suppose more was working, what else would that be happening (for the community)? The key here is finding what they have in common as well as discrete needs.
Get people thinking about actions by asking them what the larger group and some of the individual stakeholders might do to make progress right away. Don’t let them walk away thinking you are solely responsible for change
Read back to the audience a long list of the purposeful things they said. Let them see you have been actively listening. Don’t promise lots of change, but instead offer progress – thanks to their input.

Help stakeholders make progress by engaging with them to notice what everyone has in common about the need. Help them see they can have a role in making it happen with the support of the organizing body. Stakeholder consultation is a key change tool that creates vibrant strategy.

Don’t forget to leave your comments below

Alan Kay is a change management consultant specializing in management development, strategic planning and customer experience implementation. As a former senior executive in the advertising and marketing communications industry, Alan was Managing Director of the high profile Toronto advertising agency, Harrod & Mirlin.

Since founding The Glasgow Group in 1994, his busy consulting practice counts a diverse group of Canada’s for-profit and nor-for-profit organizations among its clients. Strongly focused on accelerating strategic and human change using existing resources, Alan’s work is widely influenced by the theory and application of Solutions Focus which enables attitudinal and behavioural change within an organization. Some of his consulting work has been featured in the book, The Solutions Focus, by Paul Z. Jackson and Dr. Mark McKergow. Committed to sharing his knowledge and experience in marketing communications and strategic management, Alan also teaches executive development students at Schulich School of Business, York University. For further information, visit www.glasgrp.com or contact Alan at [email protected].

The Outstanding Business Analysis Moment in America Goes to OBAMA!

Written by Marcos Ferrer on March 16, 2010. Posted in Articles.

This year the O.B.A.M.A. award goes to the man himself, for his live demonstration of meeting management soft skills for over seven hours, on television! This is NOT POLITICAL – it is just an observation that President Obama is practicing these skills in the face of a very chaotic stakeholder environment.

So, what skills?

How about K.I.S.S.? Obama presented four problem issues, to be discussed, each quite easy to understand.

How about facilitation with detachment? He focused on the problems, did all he could to avoid the personalities, while constantly returning the focus to the issues at hand.

How about managing unproductive contributors? Every meeting has its baggage in terms of folks who simply won’t participate in the agenda, are not interested in the problems to be solved, and use the meeting to grind their own axes. Next time this happens to you, remember Obama, and his kind rebukes (Senator McCain, the election is over!).

How about preserving stakeholder interests? Even as strong differences of opinion deadlocked the conversation, Obama kept reminding the participants that real people were being affected by the paralysis. The imaginary people that are against government regulation of healthcare DID appear on Fox News – like the senior citizen who ranted against Obama’s plan, from her Medicare paid nursing home bedroom.

By letting the issues contrast against the personalities and private agendas, Obama did NOT win over the objectors to the “project” – they remain determined to keep the status quo. What he did accomplish was to create a forum where the undecided can try to weigh the issues of problem solving against ideology, so at least they know what they are deciding. Helping stakeholders decide is often as good as it gets for a BA.

Rather than dwell on the negative, I ask my kind readers to send me THEIR examples of an Outstanding B.A. Moment in America – we are seeking a right wing nominee, for a fair and balanced presentation!

Have fun, and please let us have your comments.

Don’t forget to leave your comments below

Who’s on First

Written by James Rivera on July 7, 2009. Posted in Articles.

Who’s on First is one of the greatest and funniest comedy routines of all time, and in 1999, Time magazine named the routine Best Comedy Sketch of the 20th century. This routine still stands up today because it illustrates a universal truth we all understand and have experienced: that just the slightest misunderstanding in simple common terminology can lead to a complete breakdown of communications.

In this skit Costello plays a peanut vendor and fan of the St. Louis Wolves Baseball team, and Abbott is the team coach. Costello wants to know the names of the team’s players so he can “say hello if he meets them on the street.” The source of the miscommunication is the players strange nicknames that are interpreted by Costello as non-responsive answers to his continual questioning. The lineup for the team is; Who’s on First, What’s on Second, I Don’t Know is on Third, Why is Left Field, Because is Center Field, Tomorrow is Pitching, Today is Catching, and I Don’t Care is Shortstop. Here is a sample;

Costello: What’s the guy’s name on first base?
Abbott: No. What is on second.
Costello: I’m not asking you who’s on second.
Abbott: Who’s on first.
Costello: I don’t know.
Abbott: He’s on third, we’re not talking about him.
Costello: Now how did I get on third base?
Abbott: Why you mentioned his name.
Costello: If I mentioned the third baseman’s name, who did I say is playing third?
Abbott: No. Who’s playing first.
Costello: What’s on first?
Abbott: What’s on second.
Costello: I don’t know.
Abbott: He’s on third.
Costello: There I go, back on third again!

In the end, Abbott’s explanations leave Costello hopelessly confused and frustrated. The entire time I am laughing out loud at the exchange. Inside, I cringe because at times I have experienced this same level of confusion and frustration when eliciting requirements from stakeholders due to the subtle differences in our understanding of the basic terminology such as “What are Needs?” or “What are features?” or “What is considered a Requirement?” The problem for Abbott and Costello stems from the fact that even though they think they are talking about the same thing, in reality, they are not, and for a business analyst this disconnect is caused many times by a stakeholders’ colloquialisms, cultural norms, organizational tribal knowledge, or just plain ignorance.

If Abbott and Costello had agreed on some simple guidelines before engaging in this conversation, it may have gone very differently, for example if Abbott had said.

Abbott: Now, before I tell you the names of the players, I want to make sure there is no confusion. You see, as a joke, we came up with some very strange nicknames to confuse the ball game announcers, and boy do we get a laugh.

Costello: That sounds like fun, do tell

Abbott: Yes it is, you see some players have nicknames that are actually words that are questions like “Who,” “What,” or “Why.”

Costello: Well that is really clever. I can just imagine the confusion that creates.

Abbott: Yes, you have no idea!! So for example, the first baseman chose the word “Who” for his nickname, and the second baseman chose the word “What” for his nickname, isn’t that hilarious.

Costello: Ha, Ha, Ha, oh my that is funny

Abbott: Ha, Ha, Ha, makes me laugh every time. So here are the names of the ball players.

Abbott: Who’s on First, What’s on Second, I don’t know is on Third, Why is Left Field, Because is Center Field, Tomorrow is Pitching, Today is Catching, and I don’t care is Shortstop

Costello: Hey, What about the right fielder?

Abbott: Oh, he didn’t think it was very funny so his name is just Fred.

Costello: Got it, thanks see you later

Well this is certainly not as funny as the original routine, but it is much clearer, much shorter, and no one is frustrated. This is an example of what I call “orientation.” In this modified version of the skit, Abbott, spends some time getting Costello “oriented” to the terminology to make sure the conversation gets off on the right foot. The result is clear, succinct, and frustration free communication.

To achieve this type of orientation, you have to ensure that you are relying on not just the definition of common terms, but also the semantics or meaning. The best way to do this is to begin by asking some simple clarifying questions to make sure you are talking about the same thing.

Because you will be talking about software or product development and not baseball, you most likely will not encounter such strange nicknames as “Who” “What” or “Why.” However I have encountered some awkward and perplexing interpretations of common requirements terminology that has created some very challenging communications.

To understand the right questions to ask, for example, let’s first lay down some guidelines around two common terms, needs and requirements.

Understanding Needs

A need is a deprivation or something that is missing. In requirements terms, here are a few examples:

Something the stakeholder or a customer cannot do

“Customers do not have the ability to pay the bill from their cell phone.”

Something the stakeholder or a customer cannot do adequately

“The call centers experience high call volumes due to difficulties customers have paying their bill on their cell phone.”

Something they cannot see or don’t have

“The monthly call center report does not provide details on customer complaints by region.”

When thinking of clarifying questions, remember you are trying to determine what is missing or what they are deprived of, here are some guidelines.

Questions that pertain to something the user is attempting to do that they cannot do today
Questions pertaining to information that is lacking or insufficient to perform a task or make a business decision.
Capabilities that are insufficient, cumbersome, or prevent the user from performing a business task
Capabilities that cannot be performed in the correct order, or performed in a timely manner

You will notice that I am intentionally avoiding the use of the word “need” when suggesting clarifying questions about needs. The reason for this is that it is very common to confuse needs with requirements mostly because in our every day lives we don’t make the distinction between the two. I can remember my children telling me how much they “needed” the hot new video game, and I would very calmly tell them. “Well actually, you do not need that hot new video game, the only things you need are food, shelter and love, all of which your mother and I provide. What you really mean to say is you “want” or “desire” to have a new video game. As you can imagine, my children just roll their eyes, complain louder, and typically get their way.

Needs are not necessarily tangible things; they are a description of a condition or state. Much like hunger is a physiological condition that results from the lack of food, a need is a business condition that results from the lack of a capability. Make sure when you are discussing needs that you are talking about conditions or states of deprivation, and this will ensure that you are talking about a need and not something else.

One other distinction in regards to needs is whose needs you are referring to, business needs, customer needs, stakeholder needs. This distinction is based on who is experiencing this condition or state. In other words, who cannot perform the task, who cannot see what they want to see, or who is having an inadequate experience.

Understanding Requirements

Requirements on the other hand, exist only to satisfy needs. Requirements can also be classified as desires or wants unlike needs which specify something that is missing. There is a very important relationship between requirements and needs, and you must be able to demonstrate this relationship to ensure that you have a valid requirement. The following example also demonstrates that there are typically many requirements necessary to satisfy a single need.

Here are some examples:

The “Pay by Cell” feature will provide the customer with the following capabilities:

The system will provide the customer with the ability to look up their existing monthly bill on their cell phone.
The system will provide the customer the ability to pay by credit card on their cell phone
The system will provide the customer the ability to store their credit card information from their cell phone.

Note: you will notice I cleverly inserted the term “feature” without any explanation. For clarification, in this example a feature is a collection of requirements which also exist to satisfy a need.

When thinking of clarifying questions, remember you are trying to determine what capabilities will satisfy or fulfill a specified need. Here are some examples of categories of questions to ask:

Questions about how a specific capability will help the customer to perform a task they could not perform before
Questions about how having specific information will help the stakeholder make better business decisions or perform specific tasks
Questions about how specific sequence or timing of capabilities will provide a better experience for a user

A good rule of thumb is to avoid using the terms you are trying to clarify in a questions, such as What do you Need? What do you Want? or What do you Require?

Remember requirements exist to satisfy a need or condition. Much like food satisfies hunger, requirements satisfy needs. Also, like needs, you must also make the distinction between the various types or sub classifications of requirements such as customer requirements, business requirements, system requirements, product requirements, technical requirements, etc. This distinction is very important because the methods used to document these different types of requirements can be substantially different.

In the previous example, the requirements were specified in a functional form, that is to say, they describe the requirements in terms of the functionality or capabilities the product must have to satisfy the need.

Another common form of describing requirements is in terms of the experience the user has when interacting with the product, for example;

The user requests their monthly bill from the system and the system displays the bill to the user
The user chooses to pay their bill by credit card, and the system prompts the user for credit card information
The user chooses to store their credit card for future reference, and the system validates and stores the user’s credit card information

To ensure you and the stakeholder are talking about the same thing with regard to the style in which to document the requirements, here are some useful guidelines to ensure you both have the same perspective.

Should the requirements describe the experience the customer/user has when interacting with the product or service?
Should the requirements describe the capabilities that the product/service must have to support the customer interaction?
Should the requirements describe the capabilities the organization must have to support the customer interaction and the product/service capabilities?
Should the requirements describe the technical capabilities that must be present to support the customer interaction, product/service, and organizational capabilities

I have seen many different terms used to describe these four types of requirements, some that make sense and some that don’t, however, what is really important is that you use the guidelines above to ensure that you and the stakeholder are talking about the same thing, and then you can agree on what term to use to describe the final artifact.

For example, I have seen the following

Use Case, User Requirement, Business Requirement
Product Requirement, Functional, Non-Functional, System Use Case
Operational Requirement, Business Use Case,
Technical Requirement, System Use Case

Again it is all a matter of perspective and what is most important is that you and the stakeholder are talking about the same thing.

Is summary, the key to ensuring that you have a productive requirements elicitation experience is to first ensure that both you and the stakeholders are oriented to the same understanding of the goals to be achieved. These goals include, ensuring the needs are well understood and documented, ensuring there is a common understanding of what is and is not a requirement by associating with a defined need, and ensuring you clearly understand the perspective from which the requirements are to be written and agree to the final style of documentation.

James Rivera is a Project Solutions and Services Delivery Professional with over 17 years experience in Program Management, Business Analysis, Process Improvement, Education and Instructional Design and he currently leads the Enterprise Business Analyst team at a mobile telecommunications company in Seattle. He is a Contributing Author to : The Fast Forward MBA in Project Management 3^rd Edition (Portable Mba Series) by Eric Verzuh (Paperback – April 25, 2008), where he wrote the Requirements Engineering Chapter, is a co-author of: Business Analyst Certification Program taught at University of Texas at Austin, Rutgers University – New Jersey, UNCC – Charlotte, North Carolina, and has been a Business Analyst and Project Management instructor at University of Texas at Austin, Rutgers University of New Jersey, St. Edwards University in Austin, Austin Community College, University of North Carolina Charlotte (UNCC) [email protected].

Bad-Ass BA Lessons. Part 1.

Written by Cecilie Hoffman on June 16, 2009. Posted in Articles.

Co-authored by Rebecca Burgess

Ten Steps to Becoming a Bad-Ass Business Analyst

Do you want to take your professional capabilities to the next level? Do you want to add more than just techniques to your tool kit? Wanna become a Bad-Ass Business Analyst? Here are ten opportunities to apply “intelligent disobedience” and judicious audacity to your environment to earn those bad ass stripes.

The term intelligent disobedience comes from guide dog training. Blind people who live in cities listen for the auditory cues from a traffic light turning green to tell them it is safe to step off the curb into an intersection and walk across the road. Their guide dog is trained to watch for cars that aren’t showing signs of stopping. When the dog sees danger to their human, the dog is intelligently disobedient, and stays in a “sit” position, letting the human know that they shouldn’t step into the path of danger.

Judicious audacity is the intelligent application of aggressive boldness; that is, taking control of the situation in a fearless fashion because it is the effective and efficient thing to do.

Caveat emptor: there is a significant amount of risk inherent in many of these actions, though the payoff is high. Buckle up tight, fellow BAs, here we go.

Step 1. Exploit the Hidden Power in “Menial” Tasks
Step 2. Delegate!
Step 3. Compose in Real Time
Step 4. Define Gonzo Success Criteria
Step 5. Ask the Crazy-as-a-Fox Stupid Questions
Step 6. Get Their Attention
Step 7. Schmooze those Stakeholders
Step 8. Rat Out those Underachievers
Step 9. Speak Truth to Power
Step 10. Put on Your “Facilitator Flak Jacket”

We’ll cover the first four steps in this article. The remaining steps will be revealed in subsequent articles.

Step 1. Exploit the Hidden Power in “Menial” Tasks

We think that as we advance in our role, we shouldn’t have to do menial work. Tasks like taking notes or writing the first draft of a document or process may feel like they should be beneath us. Wrong perspective! Menial tasks aren’t always low brain power tasks; below are two examples of hidden power for the BA who can leave their ego at the door.

#1: Note taking and the power behind it

When you are the person recording the meeting minutes, you are in control of the official record of the decisions, action items, and open issues. Is the speaker making pronouncements in sentence fragments? You can stop the meeting and request that the speaker give you a statement that can be recorded. Does it appear that a decision has been made but you aren’t sure exactly what was decided? You can stop the meeting and request that someone give you a summary so that you can record it properly. Has an action item been agreed to? You have the power to suggest who should own that action item and what the due date should be. Is note taking a menial task? Hardly. You’re actually running the meeting and finalizing the decision making.

And, of course you are taking these notes directly in electronic form. Pen and paper is a luxury reserved for CEOs and poets; the rest of us have to be more efficient.

Before sending out the meeting notes, you should summarize the key points and decisions. Was there some fuzziness around a particular topic? Clarify it based on your business understanding or by contacting the Subject Matter Expert (SME). This is like stealth direction setting. And think of the visibility you have when you send around the meeting notes for comments and correction. Just be sure to have “recorded by ” in the meeting notes.

#2: Seize the moment: Draft the initial process/doc yourself

Do you ever get impatient with the lack of progress, or the inability of some people to get past a blank template? Start the document yourself and send it out to the team as a “suggestion”. The trick is to influence the process by presenting your ideas to kick-start everyone else’s thinking. Your natural BA instinct will be to try to get everything right before you show the document to anyone. In this case, though, you don’t need to get everything right because you are influencing, as opposed to analyzing; you’re pointing people in the general direction that you think is best, and encouraging them to build on top of your suggestions.

Step 2. Delegate!

Delegate? How am I supposed to delegate? I’m a single contributor, I can’t delegate; I get tasks delegated to me!

True. We BAs are single contributors, we don’t have the authority to delegate, but we have earned the right to suggest that a particular person or group should perform a task. In Step 1, above, there are two methods of “stealth delegation”:

You can delegate by recommending a person to own an action item from a meeting. If a person has special knowledge or interest in a particular area, it is appropriate to suggest they bring their expertise to bear on a task in that area. Minimally, you could ask them to draft a few slides or a couple of paragraphs outlining their ideas or concerns, which you can incorporate in the deliverable. They are likely to come up with some points you wouldn’t have thought of as well as being more invested in the success of the effort.

Delegate by putting a comment in a draft implicitly assigning a section by asking a question of a specific stakeholder, e.g., “Stakeholder A, do you have anything to add here?” Then follow up with that stakeholder both privately and publicly.

There’s also delegating by trading tasks – what can you do for the individual that you want to do something for you? This sort of “horse-trading” is a great way to leverage your own skills to obtain something you need, but can’t accomplish on your own.

In all these cases, be very clear about what you need from the person and when you need it. Follow up with them approximately half way through the time you have allowed for the deliverable to make sure it’s still on their radar. Be sure to emphasize that their special knowledge and input is vital to the success of the project and thank them for taking the time to contribute.

Step 3. Compose in Real Time

Whether you are doing a structured walkthrough of your BRD, or real time process development, when you have a live audience for work that is happening in real time under your fingertips, the pressure is on. This is one of the stages on which you earn your Bad-Ass BA performance award, if you are truly a master of your craft.

Let’s say you are using one of the many application sharing tools that allow people to see what is on your computer screen, no matter where in the world they are physically located and that you are revising the phrasing of a requirement that is giving people heartburn. Three people are talking at once. While you retype the offending requirement before everyone’s eyes, you get to say,

“Folks, let’s agree on who is the actor, here. Do we agree on that it’s the system? Good. Now, what was the exception condition that someone identified? Wait, what has to happen to trigger this requirement to come into play. One at a time folks! One at a time! Any conditions? No? Okay. Let me read this out loud to see if makes sense…. I think we want a different word, here, how about “configuration”? Any disagreement? Good. Now give me a moment to tune up the action … okay, please read this to yourselves. (count from one to five silently) Does anyone feel this does not express what we are trying to capture? Great. What’s the next one we need to work on?”

You own the stage, you clearly own the material, you are in the driver’s seat and you are getting the job done. Furthermore, you are putting pressure on the people who disagree to get their issues out in the open and resolve them by asking if anyone disagrees and explicitly making silence equal consent. The key is to determine when you’ve captured the meat of the idea and not let people wordsmith themselves to death.

How did you develop this skill? You’ve been taking notes in meetings (see Step 1, Point #1, regarding CEOs and poets) for years and doing the same thing; now you’re just doing it before everyone’s eyes and making it look easy.

Step 4. Define Gonzo Success Criteria

Slang: “gonzo” means conspicuously or grossly unconventional or unusual

As an exceptional BA, you should already have gotten all your project team members and stakeholders to focus on the success criteria for the project and the on-going process. Now take a dramatic step and get them to focus on the end customers’ success criteria for the on-going process. When you start doing this, the team members and stakeholders are likely to tell you that you are crazy and what you’re suggesting is impossible to do/measure/implement. Don’t worry, that’s a natural reaction to out-of-the-box thinking, and you are way out of the box.

The point of focusing on the customers’ success criteria is that we usually measure what is important to us, and what we feel is reasonable to measure. Too often, what we think is important is not what the customers consider important. Here are two examples to illustrate different aspects of this.

Scenario 1.

Airlines have determined that customers’ satisfaction is impacted by how long it takes to check in for a flight, so it makes sense to have a requirement that the flight check-in process be as efficient as possible, and to measure the time it takes to check in. It would be sensible and relatively easy to measure the time it takes for the counter personnel to key in the customer’s information and provide the customer with a boarding pass. If you are the customer, however, when do you start measuring the time to check in? Probably when you get in line at the counter.

So if there’s a 20 minute wait in line because the airline hasn’t staffed the counter properly, it may not matter to you that the time it takes the counter personnel to key in your information has been cut from 10 minutes to five minutes. Nor would you be impressed if they were able to cut it further to two minutes – you are still irritated by the long wait in line. The gonzo success criterion comes from looking at something that the airline doesn’t nominally control and may find difficult to measure: the amount of time spent waiting in line. Once you change your point of view to the customer’s, however, further improvement in the pieces of the process that you control may be wasted investment, compared to extending your control to other, more difficult to manage and measure portions of the process.

Scenario 2.

Software companies don’t want to give away support for their products so they generally require customer companies to pay for a maintenance license. When someone from the customer company calls in for support, the first thing the software company does is determine if that contact and company is entitled to support by checking that company’s “entitlement data”. It makes sense to the software company to make it as easy as possible for the customer companies to keep their entitlement data up to date, so the software company could have developed success criteria about how much time it takes the customer to update entitlement data. From the customer company’s point of view, however, there may be no reason to value entitlement data; the customer company just wants support, now. The customer’s success criterion is for the software company to “automagically” know that they are calling about a legal copy of the software for which maintenance has been paid.

Manual maintenance of entitlement data is just one possible way to meet that need. If the software company came up with another solution that led to the software itself automatically maintaining the entitlement data when it is deployed or updated, the customer would probably be delighted. But as long as the success criteria assumes that entitlement data must be maintained manually, the customers’ real needs are being overlooked. In this case, the gonzo success criteria requires ignoring the solution already in place and getting back to the customers’ underlying need.

As a business analyst, you are used to putting yourself in other people’s shoes to figure out what they want. Use that skill to add the end customer point of view to your requirements and metrics and you will increase your value enormously.

This is the first installment in a three-part series. The next installment will cover

Steps 5 to 8.

Installment 1 Business Analyst Times June 16/09	Step 1. Exploit the Hidden Power in “Menial” Tasks
	Step 2. Delegate!
	Step 3. Compose in Real Time
	Step 4. Define gonzo success criteria
Installment 2 Business Analyst Times July 14/09	Step 5. Ask the crazy-as-a-fox stupid questions
	Step 6. Get their attention
	Step 7. Schmooze those stakeholders
	Step 8. Rat out those underachievers
Installment 3 Business Analyst Times Aug 11/09	Step 9. Speak truth to power
Installment 3 Business Analyst Times Aug 11/09	Step 10. Put on Your “Facilitator Flak Jacket

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

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

Managing Large Groups of Stakeholders

Written by Jonathan Malkin on March 3, 2009. Posted in Articles. 1 Comment on Managing Large Groups of Stakeholders

You’ve just been assigned a new project. You’re excited to get started but then find out the customer wants to have 18 stakeholders instead of the usual six to eight. Reaching consensus with 18 people is a little more difficult than with six people. Try getting 18 people to agree on lunch and see what I’m talking about!

How do you handle a large group of vested stakeholders?

Push back on constraints
Part of your job as a business analyst is to ask the tough and uncomfortable questions. Why does each of the 18 people need to be at this meeting? Is each person a decision-maker or a provider of information? Six providers of information were asked to provide their data in advance. By providing information ahead of time they were no longer required at the meeting. Why are they there?
Double the estimates for all work
Reaching consensus in a meeting is one thing. Reaching consensus on document reviews once everyone has gone back to their regular work schedule is another. Make sure to double the expected turn-around time for all document reviews or other work requiring participation of all stakeholders.
Organize the team
Make sure each person on your team knows his/her roles and responsibilities.
In our meetings typically I present, facilitate, and generally do the “song and dance”. The project manager documents decisions, action items, why decisions were made, and anything else that may help. The subsequent work of managing the project schedule, conducting analysis, and other key tasks is also clearly divided.
Expect additional work
Additional tasks will “spring up”. The project sponsor may request reviews, demonstrations, or other key meetings to keep abreast of all decisions and changes. Make sure to do whatever it takes to make this person happy. After all it’s the project sponsor who ultimately calls the shots and signs your check.

In my recent experience, a project sponsor wanted to see the “user experience”. I created a document including a flow chart and screen shots walking through a simple purchase scenario. We reviewed the document, demonstrated a live system and answered all of her questions. The project sponsor was given a clear picture of the system she purchased and was able to assign additional tasks to her staff.

In summary, with a little planning and preparation, working with a large group of stakeholders can be a rewarding experience that asks you to work in new ways, to be patient and flexible, and to improve your skills.

Jonathan Malkin is a Business Analyst at Plateau Systems. Jonathan provides configuration, integration, documentation, and deployment support services for a leader in Talent Management Systems. Jonathan’s areas of support include 21 CFR Part 11 Validation, SF-182’s, EHRI compliance and customizations to COTS software for which he has won multiple awards. His experience includes work in the federal government, telecommunications, mortgage and banking, and custom software development industries. Plateau Systems is a leading global provider of adaptable, unified web-based talent management software, content and services to onboard, develop, manage and reward talent.

Jonathan may be reached by email at [email protected] or by visiting his LinkedIn page at http://www.linkedin.com/in/jmalkin