Skip to main content

Tag: Facilitation

Ace the Facilitation. Face Your Fame!

Written by Marcos Ferrer on . Posted in Articles. 2 Comments on Ace the Facilitation. Face Your Fame!

Let’s face it – the most excellent people skills are rarer than we’d like – even in ourselves sometimes.  Even as we try to gain the trust and confidence of stakeholders, we are constantly being judged on our performance.  It is rare that excellent documentation can make up for hurt feelings or trashed relationships.

All your thinking, analysis, problem solving will gain you naught, if stakeholders get the word that you are a jerk, or an idiot, or can’t control the jerks and idiots that come to your meetings, or can’t elicit effectively in interviews.

So here are some tips and how to use them:

  1. Set expectations at your elicitations – remember that you are collecting requirements (stated), to turn them into requirements (confirmed), but that decisions to build are completely separate from the discovery process.  Be honest with your stakeholders – you don’t make the decisions, you make sure that all inputs are considered in their proper context.  Most stakeholders understand that priorities come into play; they just want to know that their input wasn’t ignored, or heard by an ignoramus.
  2. Get your attitude right – get neutral – if you favor some stakeholders over others, participation will decline, buy in will decline, and sniping will increase.  It is OK that some ideas rise higher than others, just make sure that you aren’t perceived as a “teacher’s pet”.  Make sure that ALL your stakeholders feel like the teacher’s pet.
  3. Do NOT judge ideas, or try to correct them, when offered.  Capture them, use them to stimulate further discussion – the secret to comedy improvisation is to always say yes to your partners – be encouraging, not judgmental, and don’t allow your knowledge of potential solutions interfere with your goal of completely understanding your stakeholders – completely!
  4. If your stakeholder refuses to cooperate because your project isn’t important to them, get them to talk about what is important to them.  Intersections with your project will arise surprisingly often, and when they don’t, file the stakeholder interview against future projects – as trust builds, you will get them!
  5. When a stakeholder gets angry or emotional in a meeting, use the “attitude ladder” to connect with them rapidly and effectively, and bring them down.  The key is to understand that the emotions about the requirements effort can range from completely negative, to neutral, to extremely positive.  When a stakeholder goes negative, MATCH their emotion with a little (little) of yours, them bring yours down and see if they will come with you.  Example:  LOUD: “This meeting is a waste of time.  No one asked us if we even wanted this, and we are really busy!”  Response:  NOT QUITE AS LOUD: “I GET how frustrating this is for you!”  CALMER:  If we agree to keep it really short, can we focus on the assignment for the short time we take?”
  6. Use humor – always risky, and yet the right joke can take ALL the tension out of a room.  Safer to focus humor on yourself, such as:  “This meeting is idiotic!”  Response:  “I resemble that remark – that is why I have to ask all these questions!”  Use with caution.
  7. Don’t use WHY.  Don’t argue with me, just don’t do it.  Don’t ask me WHY, or I will ask you “Why don’t you already know this?”  Any WHY question can be changed into a WHAT, HOW, WHERE, WHEN question.  Example:  “WHY is it important to do X,” can be turned into “WHAT happens without X in place?” or “WHAT will change, given a project to do X.”  No, don’t quote “Root Cause” at me – Why are you still confused?”
  8. Prepare, prepare, prepare – put yourself in the stakeholder’s shoes and think of everything you can that might be of concern to them.  Don’t use your preparation just to control the encounter – use it to allow the encounter to flow comfortably for the stakeholder.  When you are ready for most things to come up, it is not stressful if things wander, and it can be productive. Over- Control is NOT loved, and don’t think they don’t notice when you do it.
  9. Here is a neat link – some homework, for my diligent readers. http://www.leadstrat.com/

Learn How to:

  • Prepare for a successful engagement/meeting
  • Gain the groups interest and support from the start
  • Get executives to transfer their power to you
  • Keep the group focused
  • Handle disagreements and dysfunctional behavior
  • Guide groups to effective business solutions
  • Reach consensus around a decision
  • Close the session with clarity and commitment

DO NOT DO THESE IDEAS IF YOU DON’T LIKE BEING POPULAR.  Your phone will ring too much.

Thanks to all my discerning readers – until next month, when we talk more of QA, BA, Deming and some reader responses!

Don’t forget to leave your comments below

Facilitating a Requirements Validation Meeting with Ease!

Written by Dana Brownlee on . Posted in Articles. 1 Comment on Facilitating a Requirements Validation Meeting with Ease!

The Problem

 Ensuring that a requirements document is accurate, complete and fully supported by key stakeholders, can be critically important.  Unfortunately, requirements validation sessions can be protracted and challenging.  Often, the goal of the session is to gain agreement among various stakeholders on a lengthy, detailed requirements document.  This can certainly be a tall order, but it can be done! 

Consider these Suggestions

  • Ensure that all key stakeholders are present at the session. Oftentimes, senior managers or other extended team members will participate in this important session. Ensure that the meeting is on their schedule far in advance.
  • Conduct pre-meetings with relevant functional groups to work out the details, review appendices, etc. Ideally, there should be no major surprises at the validation meeting.
  • Ensure everyone comes to the meeting prepared by expressing the importance of each person reviewing the document in detail. Give the group a choice of whether to review the document in detail during the session (2 day offsite) or review it individually offline and only conduct a high level review and discuss questions during the validation session (2-3 hours). Most groups will opt for the shorter meeting.
  • Ask participants to send their questions three days prior to the session and follow up with anyone who has not sent their questions by the stated due date.
  • At the beginning of the meeting ask each person to introduce themselves and their role in case there are new faces in the room. Also, provide a high level overview of the project before getting into any detailed requirements discussion to ensure everyone has appropriate context.
  • Define any assumptions or acronyms at the beginning of the meeting to avoid misunderstandings
  • Assign specific SMEs to lead the discussion for individual sections of the document.
  • Ask for a volunteer to be the timekeeper and another to document key decisions or action items on a whiteboard or flipchart.
  • Ensure that the requirements document is well organized with prioritized requirements.
  • Post IEEE standards for well formed requirements (Accurate, Consistent, Complete, Traceable, Prioritized, Unambiguous, Modifiable, Verifiable and Testable) on the wall (or on a slide if using collaborative software). As you review individual requirements, ensure that each requirement meets this checklist.
  • Document traceability within the document and across documents.
  • Let participants know that signatures will be expected at the conclusion of the meeting. Ensure that participants sign the document on behalf of their organization.

Don’t forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. a boutique professional development corporate training firm.  Her firm operates http://www.professionalismmatters.com/ and http://www.meetinggenie.com/, an online resource for meeting facilitation tips, training, and instructional DVDs.  Her latest publications are “Are You Running a Meeting or Drowning in Chaos?” and “5 Secrets to Virtually Cut Your Meeting Time in Half!”  She can be reached at [email protected]. 

The Business Analyst Facilitator Role in an Agile Software Development Team

Written by Mark A. Monteleone on . Posted in Articles. 1 Comment on The Business Analyst Facilitator Role in an Agile Software Development Team

The purpose of this article is to define the need for the business analyst facilitator role in an agile software development team. Traditionally the business analyst role has been defined in the context of a project, utilizing the waterfall solution development life cycle (SDLC). This approach has the business analyst collecting all the requirements and business rules upfront prior to development. However, today’s demand for accelerated solutions has changed the dynamics of system development to a more agile approach, where requirements and business rules are defined in conjunction with solution development in iterative cycles. Hence, the question – “Is there a need for a business analyst role in an agile software development team?”

Some readers of this article may believe that the business analyst role is not needed with the agile approach. To those of this position, I encourage you to read on. I suggest regardless of the SDLC chosen (waterfall or agile), the role of the business analyst is still needed. As a developer, you may say, “but we are doing fine on my agile project without a BA role.” To you I ask, “Have you examined your expanded role of directly interfacing with stakeholders?” For the past 40 years in the IT business, I have experienced several approaches to solution development. One rule that does not seem to change is that regardless of the SDLC used, functions that roles provide remain. In the agile case, BA functions are absorbed by members of the software development team at some risk.

Please note, I am assuming that the reader is familiar with waterfall and agile SDLC approaches, so I will not attempt to define them in detail in this article. For the purposes of this article, a Scrum like process for the agile approach is used.

As an instructor of business analysis techniques and practices, I often field questions on the role of the business analyst (BA) in an agile software development team as opposed to the traditional waterfall solution development life cycle (SDLC) approach. After much thought and input from many sources, I am convinced that the role of the business analyst facilitator is needed in an Agile Software Development Team.

The Role of the BA Facilitator

The role of the BA facilitator is to guide activities on developing both the vision and software solution. The key word here is guide. The BA facilitator role provides process to group settings and avoids participating in content. Typically, the BA facilitator role serves as the liaison between stakeholders, and the stakeholders and software development team respectively. As the liaison, the BA facilitator role uses various techniques and emotional intelligence skills to assist project sponsors and/or team leaders in accomplishing group meeting goals:

  • Facilitation Techniques for Identifying Solution Features
    • Creating a Solution Vision and Scope
      • Brainstorming – discussing of ideas
      • Brainwriting – submitting written ideas for discussion
    • Eliciting Features and Associated Business Rules
      • Focus Group Meetings – soliciting opinions
      • Joint Application Design – resolving conflicts
    • Analyzing Features – Assumptions, Constraints, Risks, and Issues
      • Root Cause – five whys, Ishikawa Diagrams
      • Force-Field – listing negative and positive influences
      • As-Is and To-Be Gap
    • Making Decisions on Features and Priorities
      • Multi-voting – subjective paring down a long feature list
      • Criteria-Based Grid – weighting feature value criteria
      • Impact/Effort Grid – comparing feature benefits versus effort
  • Emotional Intelligence Skills for interfacing with stakeholders
    • Active Listening and Paraphrasing
    • Generating Participation
    • Neutrality – focus on meeting process instead of solution content
    • Questioning – seeking answers rather than posing solutions
    • Maintaining Focus – use a parking lot and issue log for off agenda topics
    • Obtaining stakeholder feedback
    • Summarizing and synthesizing Ideas
    • Conflict intervention

Under the agile SDLC, the BA facilitator role contributes in two main activities: Continuous Vision and Scope Sessions, Iterative Software Development Meetings and Workshops.

Every project starts with a vision and scope of the solution to meet a business need. This vision may be definitive or fuzzy. However defined, the vision will reflect a prioritized set of high-level solution features that is essentially the scope of work to be done by the software development team. In the agile approach, defining the vision and scope is a continuous set of sessions. Each session represents a snap-shot of the vision and scope at that time determined by the stakeholders. These sessions manage the scope of solution features either as additions, changes and/or refinements until the stakeholders complete their vision.

These vision and scope sessions are chaired by the project sponsor. The challenge for the project sponsor is to ensure that the project vision and scope is a collaborative effort among all the stakeholders, hence the need for the BA facilitator role. The role of the BA facilitator is to assist the project sponsor by providing and executing session plans. Each vision and scope plan consists of:

  • ensuring the correct participants attend
  • accounting for meeting risks
  • arranging for an adequate facility conducive to collaboration
  • setting an appropriate agenda

This agenda contains facilitation techniques that will lead the stakeholders to a consensus on a prioritized set of high-level solution features to be pursued by the software development team. During the session, the BA facilitator role uses emotional intelligence skills to ensure that all stakeholders participate and that their ideas are respected. The BA facilitator role ensures through “questioning” that the features are justified and can be traced back to the business need. Note that all features are subject to the approval of the project sponsor – chair of the session.

Iterative Software Development Meetings and Workshops

After the initial vision and scope features are determined, the Software Development Meetings begin with a consensus on which of the prioritized set of high-level features will be developed on the first iteration. Once a finite set of features is selected and time-boxed by the software development team, then a series of follow-on status meetings are held addressing progress and the removal of impediments. Between these status meetings, the software development team holds workshops with stakeholders to develop the solution. These iterative workshops conclude with a validation meeting of the developed solution and a decision on implementation by the project sponsor. In summary,

  1. Select vision and scope features from prioritized list
  2. Develop a solution for this iteration within a time-box
    1. Conduct workshops producing prototypes
    2. Hold status meetings on progress
  3. Validate final prototype and implement with project sponsor approval
  4. Return to step one for further features and add rework as needed until feature list is exhausted

Note that with implementation, the iterative software development meetings are renewed by another selection of prioritized high-level features to address. These features may have been changed by the stakeholders in the meantime by further vision and scope sessions held in parallel with the software development meetings.

The feature selection and status meetings are chaired by a team leader similar to a project manager. In these meetings, the team leader faces the same challenge as the project sponsor – ensuring that solution development is a collaborative effort through consensus. Once again there is a need for a BA facilitator role. As in the vision and scope sessions, the role of the BA facilitator is to assist the team leader by providing a plan for each meeting and executing that plan.

The software development team is self-directed and/or self-organized. The team runs the workshops according to their skills and experience, rather than using a set plan by the team leader. The workshops are direct conversations between the software development team and the stakeholders. These workshops involve vital business and technical details in developing the solution:

  • User and system functional requirements
  • Associated business rules
  • Information needed to be managed
  • User Interface
  • Technical implementation methods

Both what needs to be developed and how it is to be implemented are discussed at the same time during the workshop. As a result of these discussions, the development team provides a solution through a series of prototypes each tested with direct stakeholder feedback. The final prototype (for this iteration) is then validated and approved by the project sponsor for implementation. A new cycle then starts with the selection of further features from the vision and scope including possible rework items….etc, etc, etc.

In the workshops, the role of the BA facilitator is different from the previous planning meetings. During the planning meetings, the BA facilitator role provided and executed an agenda. The role of the BA facilitator in the workshop is to assist the stakeholders and the software development team to determine system requirements from stated user requirements for the purpose of building prototypes. The software development team uses these prototypes to build an incremental solution.

The BA facilitator role accomplishes the above by using an expanding BA tool which includes:

  • Business Modeling Tools for identifying and analyzing user requirements, system requirements, and business rules
    • Activity Workflows with Swim Lanes – manual processes
    • Use Case – user / system dialogue – system functional requirements
    • Storyboard – user / system interface – screen flows
    • Entity-Relationship – organizing information used by the system
    • State Change – information changes as it proceeds through processes and systems
    • Class / Object – use for Object-Oriented implementations

The thoroughness with which Business Modeling is used by the BA facilitator role is tempered by the needs of the software development team. Rather than comprehensive documented requirements as in the waterfall SDLC, the BA facilitator role generates “just enough” documentation as needed by the software development team to code the prototypes.

Conclusion – Formal BA Facilitator Role “Just Ensures”

Whenever solution features are being defined, prioritized, analyzed and/or developed, the BA facilitator role is used naturally to ensure stakeholder buy-in and acceptance of the final solution. Whether it is the vision and scope sessions, the iterative software development meetings or the workshops, the BA facilitator role may be taken on by a member of the software development team. However, consider the risk involved in building a consensus with someone less trained and experienced in BA facilitation. The level of productivity and consensus is directly dependent on effective use of the BA facilitator tool set. In addition, there is a risk that the stakeholder and the developer will focus on the technical aspects of the prototype rather than requirements. It is prudent to avoid this risk. To “just ensure” the success of the team, a formal BA facilitator assisting the agile software development team needs to be that best practice.

Don’t forget to leave your comments below

Mark A. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF). Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

This article first ran in the IIBA newsletter February 2009.

Tips and Tricks for Facilitating Conflict Resolution

Written by Elizabeth Larson on . Posted in Articles.

We all know that conflict is a difference of opinion and therefore neutral-neither good nor bad. Right? But try telling that to a project manager or business analyst embroiled in conflict. Conflict can threaten to destroy the team and sabotage efforts to elicit requirements. But it doesn’t have to. Having a strong, neutral facilitator and a process for conflict resolution can reduce tensions and bring about a positive outcome.

Early in my career I was a liaison representing the interests of a large branch of a national bank. I was on a committee that met monthly to prioritize requirements. Each month I met with my branch management to determine their needs. Each month I and liaisons from the other branches would argue about which new systems and enhancements should be given priority. There was no formal facilitator. Conflict was rampant and remained unresolved. I don’t remember much being accomplished in these meetings. Each branch came in with its personal agenda and each of us went away unsatisfied with the results. Time after time I was in the unenviable position of having to tell my management that they weren’t going to get what they wanted. Again!

In retrospect one of the things I should have done was to spend time understanding the problem management was trying to solve. That way I could have presented a coherent set of recommendations at the monthly meetings.

Another thing I should have done was to meet individually with key representatives before each monthly meeting to discuss our concerns, find common ground, and build relationships. Instead of returning empty-handed each month, I should have returned with a recommendation that helped not just our bank, but the entire network of branches across the country. Everyone would have benefited.

Finally and maybe most importantly, the meetings would have run more smoothly if we had had a facilitator to tell us where we were going and keep us on track.

Many years later I learned that when conflict is preventing important tasks from completing, having a facilitator and a facilitation process is essential. Such a process might include:

  • Find a neutral facilitator. When emotions run high, it is important to find someone without a vested interest in the outcome. Some BAs and PMs take turns facilitating meetings for each other. Some organizations or PMOs provided facilitation services. What’s important is having a designated, neutral facilitator role.
  • The facilitator should set ground rules. One ground rule that can be used for conflict situations is that the participants will disagree with ideas and not people. This helps prevent the discussion from turning personal. If the discussion becomes emotional, the facilitator needs to bring the focus back to the issues at hand. If this is not possible right then, the meeting should adjourn.
  • Take time to understand the problem. Conflict arises for a variety of reasons. People have personal agendas, they think their way is the right way, they want to be recognized as experts, etc. We need to understand the real needs behind the stated needs, the issues behind the positions.
  • It is important for those in conflict to resolve it themselves. Once all participants understand the problem, we need to hold a brainstorming session to generate ideas to solve the problem. This can be done individually or in a group. Sometimes it is useful to have the participants write ideas on yellow stickies. It is important at this point to concentrate on generating ideas to solve the problem, not to evaluate the ideas presented.
  • Prioritize the solutions that have been generated by comparing approximate costs and benefits. You may need follow-up action items to quantify both the costs and benefits of the solutions.
  • Another facilitated session may be needed to develop a recommendation, or the recommendation can be assigned to one of several of the participants.
  • Present the recommendation to a pre-determined decision-maker, such as a project sponsor. It’s important to have a designated tie-breaker to ensure the conflict is resolved.

These steps will not prevent conflict, which is a natural part of a project. But they will help keep the project on track and prevent ruined relationships.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]

Facilitating Discovery Meetings; Be Prepared

Written by Richard Lannon on . Posted in Articles.

When I was a Boy Scout we had a simple motto; “be prepared”. The same motto applies to facilitating discovery sessions with your stakeholders. In general, people are tired of attending meetings and discovery sessions. In the business world, business analysts, project managers, senior managers and all other stakeholders are busy people who deserve to have their time leveraged wisely. Here are some of the techniques you can use to get participation, gain consensus and leverage your stakeholders in discovery sessions and meetings.

  • Get your introductions established with key takeaways from the participants. This helps the facilitator align the session objectives with stakeholders expectations. 
  • Establish the “rules of engagement” and “who they are as a team”. The rules of engagement provide a context for the session structure and acceptable behaviours. The team question helps establish how the participants see themselves. 
  • Be clear on the “business problems” being addressed and the “solution context”. Clear business problem definition should be created in partnership with the sponsors and senior stakeholders prior to the session. The solution context provides a framework for the participants to frame their thinking in addressing issues. It does not mean the facilitator is providing solutions. 
  • Use a variety of people and group dynamic tools and techniques. For example,
    Brainstorming in a non-judgemental way to capture the thinking of individuals and teams. Make sure that you follow brainstorming rules.
    Buzz Groups to buzz on an assigned topic for 10 to 20 minutes that have been established by the facilitator.
    Team Pods to group people into working units at common tables facing one-another so they get engaged.
    Play games. Do not be afraid to play games. Games provide a means of getting participation engaged and the information you need to have a successful session. This is where your creativity comes in. Have fun!
    66 Technique. Six people discuss a topic for six minutes. Give the group structure by assigning a chair, a scribe and an auditor to provide feedback on the groups’ efforts.
    POPs. Get the POPs (points of pain) and align them with the organizations maturity.
    Nominal Group Technique. Use the Nominal Group Technique to have team members identify their best solution to business problems through a process of rating and elimination.
    Cost, Ease, Benefit. Use Cost, Ease, Benefit analysis to have participants clearly define and understand the impact of their recommendations.
    SWOT. Get the SWOT, that is strengths, weaknesses, opportunities and threats, and identify those things external and internal that the team needs to focus on.
    Fish Bone. Throw them a Fish Bone (a diagram) to stimulate ideas and thinking as to the root cause of a business problem.
    Debate Teams. Create Debate Teams and have the groups discuss all sides of an issue. Ensure that there is structure and everything is timed and scribed.
    Smart Objectives. Have the groups make objectives SMART through ensuring they are specific, measurable, attainable, relevant and timely.
    Implementation Plan. Build an implementation plan with assigned tasks, core responsibilities and timelines. Ensure there is a follow up mechanism.
  • At the end of the session there are a few other things the facilitator should do. Consider these items:
    Summarize and Review all that has been said to ensure clarity and alignment with the sessions key objectives.
    FUDs. Get the FUDs (fears, uncertainties and doubts). Have the stakeholders write these down, in confidence, and hand them in at the end of the session. There is nothing better than knowing the stakeholders concerns.
    Communication. Establish a follow up plan. Communication is key to understanding what the participants expect. Be clear on expectations and follow through.
    Positives and Deltas. Request the positives and the deltas regarding the session. Review these as they will provide the facilitator insight into areas for improvement.
    Scale it 1 to 5 and ask how the stakeholders feel about the decisions, recommendations and the overall initiative. You might find that they see things as just another shade of what they did last year. Be prepared to leverage the information gathered.
    Get yourself evaluated. You need to grow.

There are lots of approaches, tools and techniques that you can apply to creating discovery sessions and meetings that provide value to the participants and stakeholders.

Your job? Be prepared!

Richard Lannon is an international business and technology industry veteran turned corporate speaker, facilitator, trainer and advisor. He specializes in aligning the enterprise and technical skills to common business objectives. Richard helps organizations and professionals identify what’s important, establish direction and build skills that positively impact their bottom line. He provides the blueprint for your organization to be SET (Structured, Engaged and Trained). His clients call him the SETability Expert. He can be reached at [email protected] or 403-630-2808.