Tag: Team

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.

Business Analyst Team Kick-off Practices

Written by Terri Moulton on July 27, 2009. Posted in Articles.

Start your team off on the right foot, whether your project uses an Agile or Plan-driven project method, by ensuring that your team kick-off activities set accurate expectations and reinforce how you will work together. As the role of the business analyst begins to include more project management work, there are opportunities for business analysts to gain visibility and increase their business value within their organization.

Specifically, business analysts can take a larger role in designing and facilitating Team Kick-offs and Working Sessions, fostering productive collaboration between the business and the project team, and developing effective reliable relationships with subject matter experts. Often this work is called the “soft stuff” or the “soft side” of project work. The challenge most project professionals encounter is how to turn it into implementable work outcomes. This article focuses on the business analyst’s role in designing and facilitating Team Kick-offs and will provide specific techniques for Team Kick-offs employing adaptive or plan-driven project methodologies.

Project methodologies have been evolving from Plan-driven (e.g., Waterfall) to more incremental adaptive approaches (e.g., Lean Six Sigma, Six Sigma, and Agile). Some companies are firmly rooted in the ever popular Plan-driven methods where the entire project is defined in detail from start to finish while other organizations are evolving towards clarity and detailed definition in the short-term and are accepting of more ambiguity in future stages of the project. Of course, there are also firms who are using a hybrid approach to extract the best practices out of each method. Business analysts must understand the differences and incorporate them into their work at the activity level, not only at the theoretical level.

The Role of the Business Analyst in Designing and Facilitating Team Kick-offs

Prior to the recent acknowledgement and formalization of the business analyst role, the project manager owned the majority of the Team Kick-off activities and the business analyst was relegated to only administration and documentation. See diagram below.

Business analysts worked more behind the scenes in support of the project manager and waited for their opportunity to influence the project during subject matter expert (SME) interviews and business requirements working sessions. Now, as business analysts increase their role to include more project management activities, they can build on their current facilitation skills used primarily for requirements sessions to help the project manager develop the project team. All of this work begins with taking a more active role in the Team Kick-off. The diagram below highlights additional activities that will leverage the Project Manager, ensure their leadership positioning, and increase the business value and initial visibility of the Business Analyst.

In order to take on some of the above activities in the Team Kick-off, business analysts need to schedule meetings with their project manager to offer additional support in developing the Team Kick-off. Once new responsibilities are agreed upon, the business analyst should ask the project manager the following questions in order to begin the work:

What outcome is this project expected to deliver?
Which executive is sponsoring this work?
How is this work perceived in our organization?
When are you planning to conduct the Team Kick-off?
What are the primary skill sets and knowledge that we need on this project team?
Which organizations will you approach for resources?
Which project method will you use to complete this work (i.e., plan-driven or adaptive)?
What expectations will you set with the new project team?
How do you envision the project team operating or working together?
What expectations will you set with the stakeholders?

Business Analyst Team Kick-off Practices

How are Team Kick-off practices different for plan-driven and adaptive projects? It is important to recognize that shifting the project method does affect how work is completed at all levels in the project. See the diagram below.

All teams benefit from setting expectations up front, building trust, and understanding their shared purpose. The dimension that most increases a team’s probability for success is a clear understanding of their shared purpose. Business analysts can help drive shared purpose by designing the key messages, activities, and work approaches into the Team Kick-off. After all, project managers are known for following the plan and managing the schedule while business analysts ensure that the right work is completed within the work activities and deliverables. Shouldn’t this expertise be applied to the “soft stuff” as well? Do your project managers a favor…help them bring the team to life by focusing on the high-impact levers of project success.

To get started, visit the Team Kick-off webpage to download a FREE tool: The Team Kick-off Planner.

Terri Moulton is the Founder and CEO of CanChange. CanChange provides step-by-step solutions for common change management challenges. CanChange’s products support both individuals and organizations as they navigate change related to system implementations, process improvement and other business initiatives. To access tools, templates and additional resources for Successful Team Kick-offs and Facilitating Successful Working Sessions? Visit Terri’s website at CanChange. You’ll find step-by-step guides that will help you improve your skills and ability to design and facilitate successful requirements sessions and project kick-off meetings.

BA Times Only Special: Use the code “BABONUS” at the CanChange site to receive $20.00 off any product purchase.

Bad-Ass BA Lessons. Part 2

Written by Rebecca Burgess on July 14, 2009. Posted in Articles. 1 Comment on Bad-Ass BA Lessons. Part 2

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 installment 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

Let’s move on to activities that establish you even more into a leadership role.

Step 5. Ask the Crazy-as-a-fox Stupid Questions

Slang: “crazy as a fox” – the fox is considered a cunning creature who may choose to act in a manner that appears to be foolish or stupid, but actually advances its underlying plans, or, in the case of fox hunting, outwits its pursuers and saves its life.

All business analyst job descriptions should have these four expected duties:

Asks the questions that no one else dares to ask, and that everyone wishes somebody would ask.

“I’m not sure I’m following, it sounds like we have made an assumption that magic happens at this point in the process, and all the customer record duplications are cleaned up and removed. Could you tell me again how this is going to happen?”

Asks the questions that, once answered, will bring everyone to the same level of understanding.

It may be the case that some people in a meeting know what a particular TLA (three letter acronym) means, but others have no clue, and are having a hard time following the conversation. The “stupid” question, “sorry to interrupt, but could you tell me again, what SRM stands for?” isn’t stupid, it is a kindness.

Crystallizes the issue for people to understand what the sticking points are.

You may need to go out on a limb and take the risk of oversimplifying, but it is a risk worth taking. For example, it is not unusual for two team members to be arguing vociferously when they are actually in violent agreement. It’s your job to remove their blinders and show them how their opinions can actually dovetail. Try paraphrasing their positions, and then suggest how they can be combined.

“Let me tell you what I’m hearing. Lakshmi, you feel that A is the most important issue. Jorge, you’ve been saying that B has to be addressed first. I don’t think this is a win-lose situation. Your recommendations are not mutually exclusive if we do C, which essentially combines A and B. As for D, can we forgo it? Doing so would remove the risks we are concerned about. What would the ramifications of that approach be?”

Ask the questions that lead to out-of-the-box thinking.

One interesting “stupid’ question involves asking for the anti-solution and using the resulting suggestions to generate discussion on how to resolve those problems.

“Let’s spend a few minutes thinking out-of-the-box with the anti-solution. If we really wanted to mess this situation up, what would we do? [much laughter and crazy suggestions which you capture as discussion points] And how can we avoid point A? What about point B – aren’t we actually making that worse with this requirement we just defined? Does this raise the possibility of an entirely new solution/policy/process?

Step 6. Get Their Attention

Slang: A “clue-by-four” is a broad hint, firmly delivered. Also a metaphor for enlightenment. This term derives from a western American folk saying about training a mule: “First, you got to hit him with a two-by-four. That’s to get his attention.” A two-by-four is a standardized size for boards used when building – roughly 2 inches thick by 4 inches wide by multiple feet long.

People, unfortunately, don’t always pay attention to potential risk. Risk as seen through our BA eyes frequently has to do with the consequences of missing information. This kind of risk can be overlooked or underestimated by people who usually focus on delivery risks. The clever BA needs to not only identify the risk, but also assess the severity of the risk, and frame and communicate the risk in a way that makes the consequences clear and unappetizing.

The fact that Risk Management is usually considered a project management activity does not preclude a BA from putting this methodology into her own toolkit:

Identify, characterize, and assess threats
Assess the vulnerability of critical assets to specific threats
Determine and quantify the risk severity and likelihood of occurrence
Identify ways to reduce or avoid those risks
Prioritize risk reduction measures based on a strategy

Capturing this information in a tool like the Failure Mode and Effects Analysis (FMEA) permits you to share it with the stakeholders and get their agreement on the existence of the risk and buy-in to the risk avoidance and diminution methods. Then, when the stakeholder isn’t paying attention to a promise or deliverable, you get the joy of saying, “Madam Stakeholder? I just wanted to gently remind you that three weeks ago you promised to provide me with headcount of your developer teams so that we can estimate the number of licenses that will need to be negotiated for this third party application. According to the agreed upon risk management plan, if we don’t have the information by tomorrow at 5 pm your local time, we will have to defer all the requirements from your organization until the next phase of the project.”

Risk Management is traditionally the responsibility of the project manager. However, identifying risk is an activity that falls squarely in the lap of the savvy business analyst. Take some time to become familiar with it and the tools to support it.

Step 7. Schmooze Those Stakeholders

Slang: “schmooze” means to chat in a friendly and persuasive manner, especially so as to gain favor, business, or connections. Derivation: “schmooze” came into the English language from the Yiddish language shmues, meaning talk.

Stakeholders have the power to help you or hurt you, and if you surprise them with something, they will almost always hurt you. Make sure that they know when something is happening in your project that will touch their sphere of influence and that they buy into the change.

When you identify your stakeholders, those with the most power to help or hurt your project are the High Priority stakeholders, and should be regularly schmoozed by you and/or one of your key team members. At a minimum, meet with them regularly to keep them apprised of the project’s progress and potential impacts on their area of influence. Make sure they know who is supposed to be representing their interests, and make sure you understand what those interests are. Ask them what their success criteria are for the project, and if their idea of success is not in line with the project’s goal, perform proactive change management. Build bridges and help them understand that you are looking out for them. You will undoubtedly have to deal with them again in the future.

Step 8. Rat Out Those Underachievers

Slang: to “rat out” is to inform on, or tattle.

You’ve presented your requirements gathering plan; you believe that there is a shared understanding of the strategic direction and everybody has signed up to do their share of the work. A couple of weeks go by and everyone has completed their commitments but one team, Team Slowpoke. You did everything to ensure that all the work would come in on time. You called them a couple of days before the deliverable was due and asked how they were doing. You got a non-committal answer and they said they didn’t need help. The day of deliverable came and went. You called the next day and said that you must have missed their email with the deliverable and would they resend it. By noon. Today, Thursday. Noon came and went. It’s Friday 10 am. The entire team meets at 8 o’clock Monday morning. What’s a bad ass BA to do?

You can talk to the laggards’ peers, expressing your concern, and encouraging them to put pressure on the laggards. In parallel, you can talk to your manager and express your concern. No whining, just concern.

“Mr. Manager, I just wanted to let you know that all the teams have provided the information that they agreed to provide, except for the Slowpoke team. They have said they don’t need help. They aren’t responding to email, or voicemail, and no one is in their office. I’m concerned about what we can accomplish in our Monday meeting given their lack of participation.”

Finally, in the 8 a.m. Monday meeting, you can review all the deliverables and their status, thanking all the other teams for delivering on time, and calling attention to Team Slowpoke’s failure to deliver. You can ask Team Slowpoke’s leader, in the nicest possible way, to explain why this failure occurred so the rest of the group can help resolve the problem. You remain silent, maintain eye contact, and listen. Then you can ask how they intend to resolve the problem and what the new due date will be. In fact, you might even offer to talk with their manager, in case this is a resourcing problem and the team needs to have something taken off their plate. Use your sense of judicious audacity here, to determine how far this needs to be pushed.

The worst thing you can do is do nothing.

This is the second installment in this three-part series. In the next installment we’ll talk about speaking truth to power and that all important BA accessory, the Facilitator’s Flak Jacket.

Installment 1	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 BA 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 BA Times August 11/09	Step 9. Speak truth to power
Installment 3 BA Times August 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]