Tag: Team

Top Five Reasons BAs Need a Central Hub of Product Intelligence

Written by John Simpson on September 22, 2009. Posted in Articles.

In the world of product development, and specifically requirements management, you hear a lot about building a “central repository of requirements” or a “single system of record”. But, why does that matter? What problem does that solve? What’s the real value in creating a central hub of product intelligence?

First, let’s define central hub of product intelligence. What are we really talking about? Naturally, we think of the data (aka. artifacts or items) – the ideas, feature requests, requirements, design specifications, analysis documents and reports, release plans, defects, etc. – all the data that explains the scope of the product the team is building. The difference in why we use the word intelligence instead of data is that product intelligence expands beyond the artifacts. It also includes two other important related categories of information that support the social nature of the product development process.

Conversations. There is an ongoing dialogue throughout the product development lifecycle. Customers provide feedback. Analysts capture insights. Teams discuss requirements. Managers communicate decisions. Organizations make commitments. By including the conversations in context to the requirements and other data, your team will have the complete story of what customers need and understand the discussion as to how your team arrived at the requirements you have. The context is huge. Without context, you have higher risk of misinterpretation and defects later on.

Relationships. Often referred to as traceability (the upstream and downstream relationships between requirements and other items), the links between the data and the people who own the data are important for understanding all the dependencies, and creating a dynamic environment where you can intelligently manage and communicate changes when they occur. As a practical example, for developers working on detailed functional requirements, having the visibility to look upstream to the high-level business requirements and original feedback from the customer is huge in providing full context to what they’re on the hook to build.

Why This Matters

There are many reasons, but let’s look at these top five.

Information silos kill productivity – 42% of employees accidentally use the wrong information at least once a week.
Employees and information are fluid – they flow in and out of teams and projects constantly – what info gets lost in transition?
Employees spend 25% of their time just looking for information.
Employees waste 20 minutes or more each day recreating information that already exists.
The total information we’re inundated with grows 66% every year, so this problem will only get bigger over time.

Unproductive Stat of the Day. “It’s estimated that employees at U.S. companies waste over 5 billion unproductive hours annually just looking for information.”
– Searching Kills Employee Productivity Blog

It’s such a simple concept – capture all the relevant product intelligence in one place. Wow, that’s a breakthrough idea, right? The reality is that it’s difficult to eliminate this problem completely; it affects every organization on some level. We’ve worked at start-ups with 10 people in the same office and Fortune 100 companies with 75,000+ employees worldwide, and it exists at both. The question isn’t whether it’s an issue in your company. The more important question is, “What’s the full impact it’s having on your team and their productivity, and could a better solution make a significant difference?”

Solutions range from using back of the napkin/whiteboard to Word/Excel documents to Wikis to specialized requirements management software. You may use them all; we do. The solutions you choose will depend on your organization and the complexity of the products that you’re building. One of the decision criteria to use to gauge whether you need specialized software is to determine what degree your team suffers from the Silo Effect. Borrowing from the infamous Cosmopolitan quiz style, use the list of questions below to determine whether your team is at risk.

Take the Silo Effect Quiz

[Yes] [No] – Do you have duplicated sources of data and multiple versions of requirements spreading across your organization like the Swine flu?

[Yes] [No] – Do you have departments that are disconnected and unaware of what the other is doing? Is the right hand talking to the left hand? Be honest!

[Yes] [No] – Do you operate in an industry with compliance standards, where detailed version history and specific requirements documentation are required for approvals?

[Yes] [No] – Do you spend more than 20% of your time hunting around for the latest product information and requirements specs?

[Yes] [No] – Is visibility into the product development process limited for stakeholders? Hint: if you’ve heard or use the term “black box” in a meeting recently, then mark “yes”.

[Yes] [No] – Do you have communication gaps or blind spots related to customer commitments, feature request or other insights into what your customers need?

[Yes] [No] – Do you have frequent transitions of staff in and out of product teams?

[Yes] [No] – Do your business analysts match the 27 points of compatibility with your engineers? Sorry, ignore this one. We got carried away by the style of these quizzes.

In all seriousness, if you answer “yes” to two or more of the first seven questions above, then it’s probably time to evaluate other options to help you eliminate the silos and bring it all together into a central hub that’s accessible, searchable and reportable.

Productivity Gains from Eliminating the Silo Effect

Save time and money that’s wasted searching for information
Reduce costly guesswork, rework and related defects
Eliminate redundant research and duplicate projects
Shorten ramp-up time of new employees to the team
Give complete context to the goals and scope to everyone involved
Improve the mental well-being and sanity of business analysts (it’s not all about your company. You deserve something out of this too, right?)

Keep in mind, that having a central hub of product intelligence isn’t the end-all-be-all solution for fueling innovation. It’s just one capability in a list of many that are required to successfully plan and build products that work. If you have a broken development process, a central hub won’t solve that. If your team doesn’t have the right skill sets, it won’t fix that either. However, what we’ve found over the years is that of the myriad of challenges we face managing product development, bringing all the relevant product intelligence together in a central hub is one of the immediate and practical steps an organization can achieve right away to speed productivity, reduce costs and improve quality.

Moment of Zen: Sometimes the first step is the most valuable one to take!

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware

John Simpson, Jama Software: [email protected]

User Stories – Large Misconceptions. Part 1.

Written by Robert Galen on September 15, 2009. Posted in Articles.

One of the larger misconceptions associated with user stories is that they are static; defined once and then never touched again. Another misconception is that they stand-alone as a requirement artifact. Another is that only a customer surrogate or product owner can write them. And finally, many miss the power of the acceptance tests as a clarifying vehicle for the story.

Over my next two posts, I want to address each of these in turn. Not only should these approaches help your user story writing, but your general requirements definition clarity and understanding should improve as well. And these misconceptions also assist distributed, non-local teams in eliciting stories that are more meaningful where they struggle to maintain active face-to-face communication.

User Stories are Organic!

If you study Scrum and product backlogs at all, you’ll realize that the backlog list of user stories evolves quite dynamically over time. Usually stories are created in a Story Writing Workshop at the beginning of a project effort. In this case the stories are often ill-defined and quite large-epics or even larger.

Coming out of the workshop, there is a tremendous amount of work to do on refining the stories, but certainly not all at once. The metaphor to keep in the back of your mind is – Tip of the Iceberg! You only need to refine the stories that are 1-2-3 or so iterations (Sprints) away from actual execution.

As you move forward, delivering those pre-defined stories, you actively groom the stories moving up on the backlog-getting them prepared for execution. Typically teams groom their product backlogs weekly. The process serves to refine the clarity surrounding each story. Often it will lead to other stories-breaking them into more meaningful units and discussing dependencies. Themes or packages of stories will emerge as well, as the product owner and team think about how best to couple stories into meaningful chunks for delivery.

The last and probably most important part of the dynamic is that the team factors in ongoing progress (execution velocity) and learning into their grooming.

While working with remote or distributed agile teams, it’s important to participate in these grooming sessions as a team. In this way, everyone is involved in the real-time conversations that are naturally part of backlog evolution.

User Stories are not a Catch-All Artifact!

The key driver for the content of requirements within agile team is the team itself. Let’s say a team member encounters a user story in a backlog grooming session that is simply too ill-defined to understand or estimate. However, they do understand the story well enough to suggest that-if they had a use case with it, one that was designed like one they’ve used/encountered before, they would have sufficient clarity to proceed.

In this case, they’re suggesting supplementing the Story with a known additional artifact form.

This is great!

Instead of trying to embellish the story as-is, simply link it to the newly created use case. In fact, it’s perfectly acceptable to link stories to all sorts of well known or used artifacts in your organization – traditional requirement (SRS) specifications, forms or templates, traditional use cases, agile use cases, wireframes, etc. All can effectively come into play to enhance and supplement your understanding of individual stories.

The caveat is that you don’t want to do this for every story. Let the individual cases or needs emerge from the team! Don’t create them too far in advance and certainly don’t create all user stories with the same level of detail. These extensions must come as requests from the team, i.e., they’re pulled as needed-preferably right before the implementation in the next iteration (sprint). Thus maintaining the just-enough and just-in-time nature of your story evolution.

One of the benefits of this approach is within distributed teams. These situations typically need richer documentation density with their requirements and this approach certainly provides it, while still maintaining an agile requirements approach.

As a final note, Alistair Cockburn has spent some time establishing the notion of Agile Use Cases. More information can be gleaned here on that topic – http://alistair.cockburn.us/Agile+Use+Cases

Next post, well finish with the other two misconceptions

Don’t forget to leave your comments below

Robert Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].

Getting that Non-Contributing Team Member to Shape Up!

Written by Phil Ventresca on August 25, 2009. Posted in Articles. 1 Comment on Getting that Non-Contributing Team Member to Shape Up!

Ever asked yourself: “What are the elements that go into building a high performance team?” They are many: committed competent individuals; clear goals and objectives; well defined roles and responsibilities; excellent communication, etc. But what happens when one member of the team is less conscientious than the rest? How do you effectively deal with this individual without harming group productivity and morale?

This is an interesting and challenging question that plagues many teams in a variety of organizations. The reality is that by not responding and allowing this person to perpetuate their lackadaisical behavior, you will do more damage to the team’s productivity and morale than if you had addressed the problem head on. Keep in mind that your team wants to succeed as individuals as well as collectively. A weak link will demoralize the collective culture and allow for rapid deterioration within the spirit of the team.

I recommend an aggressive, yet compassionate, approach to the resolution of the lackadaisical behavior. Try some of the following suggestions:

Promote a performance measurement campaign that allows for visibility around collective expectations. This campaign should set measurable standards for work to be done. The core of this system can be built on schedules, work break down structures, and work packages on individual assignments.
Speak openly in the team environment about each other’s roles. Ensure that all individuals on the team understand their goals, mission and individual responsibilities. These conversations should be collaborative and constructive. Create an environment that fosters individual and collective accountability.
Provide team members with a structure around the charter, goals, values and mission for the group. Each team meeting should include reflection upon the norms created by the aforementioned items.
Remember, building an effective performance team takes time, and there may be instances along this path that cause friction for one or more members. Ensure that an open channel of communication, both formal and informal, is maintained among team members at all times.

If none of the above recommendations work to enhance the performance of this individual, more assertive and individual action must be taken. Begin an individual coaching and measurement process, which includes specific performance expectations. Meet with the team member and let him/her know about the problems their behavior is causing, and the potential negative impacts this will have on the team, project and organization.

Agree on coaching goals in writing, and set dates for periodic performance reviews. Follow up aggressively to ensure the team member’s training/coaching needs are met in a proactive manner. If the individual does not respond to the personal attention, removal from the team will be necessary. Failure to do so will promote dissent within the team, and ultimately hurt the overall performance.

Throughout the experience, communication is critical. Do not allow speculation on performance issues. Deal with the situation directly, and although the team does not need to be privy to the details of any coaching or performance improvement techniques you may be employing, make sure they are aware that you, as a team leader, have addressed the situation and are working aggressively towards a resolution. Although these types of situations are difficult, a team leader must rise to the occasion in order to preserve the integrity of the team and maintain morale.

Don’t forget to leave your comments below

Phil Ventresca is Founder, CEO and President of Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Since founding AMS nearly two decades ago Phil has lead the organization to becoming an internationally recognized provider of Consulting, Training and Assessment services. AMS’s client base is comprised of Fortune 100/500 companies, medium-sized businesses and Government agencies that Phil has personally assisted in the creation of organizational and performance based solutions.

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

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

Co-authored by Richard Larson

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

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

The Challenges

Physical Distance of Stakeholders

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

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

Roles and Responsibilities

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

Language

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

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

The Cultural Landscape

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

Tips and Techniques for Making it Work

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

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

Build Relationships and Trust

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

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

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

Define Roles and Responsibilities Using a Matrix

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

Example RACI Chart

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

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

Model the Requirements

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

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

Summary

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

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

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

Don’t forget to leave your comments below

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

Bad-Ass BA Lessons. Part 3.

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

Co-Authored by Cecilie Hoffman

This article is a continuation of the 10 Steps to Becoming a Bad-Ass Business Analyst. These steps will help you take your professional capabilities beyond most people’s expectations and help you to stand out as a leader. In the first two installments we covered:

Step 1. Exploit the hidden power in “menial” tasks
Step 2. Delegate!
Step 3. Compose in real time
Step 4. Define gonzo success criteria
Step 5. Ask the crazy-as-a-fox stupid questions
Step 6. Get their attention
Step 7. Schmooze those stakeholders
Step 8. Rat out those underachievers

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

Step 9. Speak truth to power

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

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

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

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

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

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

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

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

Step 10. Put on Your “Facilitator Flak Jacket”

Rules of the Road

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Installment 1 Business Analyst Times June 16/09	Step 1. Exploit the hidden power in “menial” tasks
	Step 2. Delegate!
	Step 3. Compose in real time
	Step 4. Define gonzo success criteria

Installment 2 Business Analyst Times July 14/09	Step 5. Ask the crazy-as-a-fox stupid questions
	Step 6. Get Their Attention
	Step 7. Schmooze those stakeholders
	Step 8. Rat out those underachievers

Installment 3 Business Analyst Times Aug 11/09	Step 9. Speak truth to power
Installment 3 Business Analyst Times Aug 11/09	Step 10. Put on your “Facilitator Flak Jacket”

Don’t forget to post your comments below

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

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

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