Subscribe via RSS Feed

Category: Requirements Definition

How to Avoid Being Stalked By Scope Creep: The Project Charter

scope-300Scope Creep. Sometimes it’s politically motivated. Sometimes it’s intentional. Sometimes it’s a misunderstanding. But it’s always painful.

What Projects and Airplane Flights Have In Common: Turbulence

I love this metaphor to help leadership, management and project teams all see the forest for the trees. Here are the key points I share:

Nobody will remember the turbulence, if the plane arrives on time and in the right city!

I used to fly quite often. One of my frequent destinations was New York. Depending on weather and other factors, it wasn’t unheard of having a flight to Kennedy re-routed to Laguardia or even Newark. In those days, it happened. But the one flight I remember best was one returning home to Chicago.

I remember one bad storm that caused our plan to circle O’Hare for what seemed like 2 hours. That delay, by itself, wasn’t out of the ordinary. The reason I remember this one trip is because when we landed, I found myself in Cleveland.

I’ve had my share of turbulent, strap-yourself-in and hold your breath, flights, that landed late. I don’t remember any specific ones. But, you better believe I remember when they re-routed us and we landed in Cleveland. I rented a car and drove ½ the night to make it to Chicago by the end of the day.

So What Did Success Look Like for My Many Trips?

  1. At a minimum: Land safely!
  2. It’s better if we land in the right city.
  3. It’s even better if we land in the right city at the right airport.
  4. I consider it a successful trip if we land within 60 minutes of our planned arrival time, in the right city in the right airport.
  5. It’s almost too good to be true if they had my preferred meal, I got a great view of a sunrise or sunset, and there was little turbulence.

And this is exactly how our stakeholders feel about our projects

  1. At a minimum, deliver “something of value”, even if late, without cancelling it due to budget and delays.
  2. If I can get all the functionality needed for the market, we’re doing better. Even with some bugs, I can work with that.
  3. And if it’s on schedule (or close to schedule) and budget, we’ll be celebrating!

But the one thing the teams should remember. Most flights have turbulence, and they run out of your preferred meals, and there’s unexpected weather and other challenges. In a year, no one will remember those details.

Make sure the project lands safely, with the appropriate functionality. Because everyone will remember the project that crashed landed.

I have another post that compares the PMO to Air Traffic Controllers. It shares best practices that helps you put in practice the lessons shared in this article. Stay tuned.

What Drives The Getting Predictable℠ Best Practices?

startIt’s all in the phrase: From the Start. I am frequently asked how the Getting Predictable Best Practices got started.

Getting Predictable℠  best practices cross many subject areas including requirements collection, tracking project progress, facilitation techniques, providing estimates that drive confidence, and so on. With such a wide array of practice areas, you’re probably wondering what binds them together. In other words, is there a common theme or vision that drives current and future best practices and recommendations? The answer is YES – there is indeed a common theme. And, as you guessed, this blog post reveals the vision aligns Getting Predictable℠ in all of its many flavors from discovery to definition through execution.

From the Start

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Wow! How profound! (Yes, I am being sarcastic at the moment but there’s truth here as well) For the majority of my career I have been on the client side of consulting relationships. I have heard some pretty big promises and I tend to be very skeptical. As I read my own description of Why Getting Predictable℠ exists, it’s hard not to think how empty it sounds! So let me explain. Let’s pretend we have a project kicking off and we have approximately four weeks to collect the overall requirements so the technical team can begin their planning and staffing of the project. So we e set up meeting with key stakeholders and business users for the first week in March to kick off the requirements gathering. The business is extremely busy and coordinating their schedules is like herding cats. All too frequently, you do not get full traction and commitment from the team during the first few days. In fact, it is possible that you might not get to full throttle until the second week of the four week schedule. Since we didn’t pad our four week plan, this lost time needs to be addressed. It is important for us to be adaptive and stay on schedule despite losing three to five days at the beginning. I want to emphasize that is not a rare situation. Especially when launching a new initiative. Would you agree?

Let’s take a different perspective…

Let me share a different way to view this. It may be a day here or a day there, but if we actually lose four to five days getting up to speed across the four weeks, we have lost 25% of schedule. We are potentially 25% late and over budget for this phase. And we haven’t even started yet! Here is my point: Although most of our leaders and managers would never intentionally handicap or put the team at risk, they are unaware that missing a meeting or pushing a date is actually doing harm to the team. If this story, in one flavor or another, resonates with you, then your success and the success of your project are being put at risk from the very start of your project. Why does this happen?

It’s all about the frog

If you put a frog in boiling water, it will immediately jump out. It’s way too hot. But if you put a frog in room-temperature water, and very slowly turn up the heat to a simmer, the frog will stay in its comfortable hot tub until it perishes. Ouch! On your project, it may only be a day here or a few folks there, not available, but before you know it, your project is starting to simmer. So let me repeat:

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Getting Predictable best practices identify and address the situations, activities and events, that can slowly handicap the teams chances of success before they even get going.

Now You’ve Got My Attention. Tell Me More.

Getting Predictable℠ Best Practices cover the gambit: Discovery, definition, execution, and organizational effectiveness models. In this blog, I focus on the best practices that address defining and launching a project or initiative. I call this set of best practices Getting Predictable℠ Definition. Getting Predictable℠ Definition addresses the three key areas that impact a project right from the start:

  • Alignment: Driving alignment around project success across all stakeholders.
  • Commitment: Developing estimates and plans the team can commit and manage to.
  • Visibility: Having a common view of progress as well as a a common definition of when the team has delivered on the defined project objectives.

In my next posts, I will discuss each of these areas in detail so you can see there is a method to the madness of Setting Teams Up For Success FROM THE START.

Facilitating A Panel Is Not So Different Than Facilitating A Requirements Session

My First AHA Moment of 2012

panel-discussion-150x150Facilitation appears to be a hot topic these days. After blogging about facilitation a few months ago, I am getting many questions about best practices and how to handle certain situations. At the bottom of this post I’ll provide links to my past articles on facilitation that should address many of these questions.

Today I want to share an AHA!

Recently I was invited to speak at an event on the topic of facilitation. One of the other presentations at that conference was a typical panel presentation.

Panels are very common at conferences; they usually have three to four people and a designated moderator who helps facilitate the discussion among the panelists and engages the audience. The session typically runs about 60 minutes.

These panels tend to be very dry (yawn)

For most panels, questions are devised ahead of time and shared with the group so they can prepare their agenda, personal messaging, and so on. I should clarify, that some panels are engaging and are very interesting. But at times, I come across a panel where each person seems to be coming from his or her personal point of view. Their views may not be clearly aligned to the question. So you get someone speaking strategically, while another may be extremely tactical or even not directly speaking to the question.

Let me magnify my point. Each member of the panel will work with the moderator to identify the question(s) they would like to be asked so they can share their viewpoint on a topic. And since three or four different panelists do this as individuals, possibly at separate times, it can be dry, without a clear set of takeaways.

I want to be clear, that there are many panel presentations that are engaging and valuable. But more often than not, I personally find them dry. As an audience member, you are trying to get a grasp of the discussion topics and understand the panelists’ points of view. However the very disparate nature of the moderator’s Q&A prevents engagement between the audience and the panelists.

Changing the dynamic of a panel…

This makes me want to try something new the next time I am invited to be a panel moderator.

I would want the audience to engage more with the panelists on stage. To get more energy, the format of the panel would have to be a little different. We are used to a panelist getting asked a question, then answering their question, followed by each of the other panelists attempting to provide answers to these preset questions which they may or may not have a valuable answer for. Then it starts all over when the next question is thrown out.

With my new approach, after the question is asked, instead of always asking all the other panelists to answer the same question, I will ask the audience members to give their perspective on the panelists’ thoughts. This would raise the engagement level of the audience with the panel.

My job as a panel facilitator would be to facilitate the rhythm of the discussion between the audience and panelists. This means I must meet with the panelists before the conference to create an agenda that would allow us (facilitator and panelists) to agree on a common objective. This would enable the panel discussion’s rhythm to flow more smoothly, be less fragmented, and not break the energy of the room.

I have already outlined in past posts, that the key to the most effective facilitators is that they monitor three things: energy, rhythm and objective of the room. The same can hold true for panel moderators (aha!)

  • Energy in the room: Everyone is engaged, participating and making constant progress toward accomplishing objectives. (For panels: Keep the audience engaged)
  • Rhythm of dialogue: The dialogue flows, but stays focused on the initial goal of the meeting. (For panels: Make sure energy does not get broken by unrelated, fragmented questions)
  • Objective of the room: Make sure the meeting stays on track and accomplishes its objective. This can be tricky since the facilitator needs to balance discussion on side topics that are helpful to the objective versus topics that derail the goal.(For panels: Make sure the questions address a common theme)

I think there would be huge value in using these fundamentals when moderating a panel discussion.

When did you last attend a panel that really impressed you and what was so unique about it?

What are your thoughts about changing the dynamic of a panel presentation?

You can find more details on facilitation best practices in my past blog posts here:

They are some of the fundamentals that I present in my regular class on Facilitation Best Practices.

Measure Twice, Cut Once

The Role of the QA in Making Software Development Predictable

measure-twice-cut-once1A Guest Post for the Getting Predictable Blog

Measure Twice, Cut Once is about having a plan, being prepared, and having a systematic approach before taking action. Whether it’s installing new cabinets in your kitchen or writing a new software application for a client, no matter what type of project you’re working on, you can minimize your chance of making costly mistakes by double checking your measurements/requirements before cutting materials or writing code.

I learned this very valuable piece of information growing up with a mother who loves to sew. As a kid I would always ask my mom if I could help. Since sewing requires measurements to be as accurate as possible, a standard practice was enforced when working with my mother to double check my measurements before I cut anything! I always thought the reason she made me double check everything was because I was a kid, until one day I noticed my mom double checking her measurement as well. So I asked her, “Why do you measure the fabric twice before cutting it?” My mother replied (as she continued measure every part of the fabric), “Because this fabric costs too much and my time is too valuable to be wasted.”

She continued to say, ”Let’s say I cut too much fabric. I have now wasted fabric because I have to cut off the extra fabric which takes time. Or, let’s say I cut the fabric too short. Now all that fabric is wasted and I must cut a new fabric layout which also takes time…”

“This dress should take me one day to make but if I’m constantly re-cutting fabric due to measurements being off, then it can take me twice as long. My original estimate of how many outfits I could get out of it will also be off. Plus, I will have to go back to the store to get more fabric. But if I just double check my measurements I save myself time, money and a headache.”

QA. (not to be confused with Tester)

This is true for IT projects as well. If the requirements (which are the measurements for a software project) are being doubled checked, the project will have a minimal chance of wasting resources, time and money.

One approach to ensure that this double check is being done is to get the QA involved at the requirements stage. While having a tester involved at this stage is not the most efficient use of resources, having a Quality Assurance Analyst (QA) definitely is.

Many IT professionals are not aware that there is a difference between a QA and a Tester. A QA is an IT professional who makes the blueprints for processes and procedures. These blueprints will ensure quality is maintained throughout the lifecycle of the project. A QA also understands how to design test cases in a way that they are competent, effective and easy to execute. A tester is someone who executes test cases that, in some cases, have been written by a QA. If a QA is involved with the requirements stage, the requirements will be unambiguous and succinct.

The QA will also check the requirements to ensure that the following has been covered:

  • Look and Feel: – How does the interface make the user feel and behave?
  • How and why the system works: What will happen when this button is clicked and why?
  • Contradictions among scenarios: Does one scenario say the opposite of another scenario?
  • Root causes for gaps in the system/process: Are scenarios defined well enough? Is the workflow depicting a different picture than the information given?

The more robust the requirements, the better the final product.

During the requirements phase, the foundation that the entire project depends on will be formed. Given that over 50% of project defects are introduced during the requirements gathering phase, it makes sense to have a QA involved to double check that gray area requirements do not get overlooked and to help define error messages and usability issues. Just like a sewing project, fundamental issues left unchecked will surface later in the project.

“Measure Twice, Cut Once” is a reminder that careful project planning will result in more predictable results.

Discovery: Going Where No Person Has Gone Before

Discovery-Going-Where-No-Person-Has-Gone-BeforeTypically, at the beginning of a project, we begin by collecting requirements from the business. We might spend a month or more gathering requirements. If we are using a more Agile approach, we may spend a few weeks gathering requirements for the first few iterations in the form of stories.

Every once in a while, I find myself starting a project where  for every step  forward we seem to be taking two steps backwards (or at least sideways).  Let me explain: As soon as the development team starts to code, literally within the first week or two of coding, the change-requests start. Does this mean the business is already changing their mind? We are just beginning to code!

So how is it that the business is changing their needs within weeks of starting a project? I can see change requests occurring once they see some initial software delivered.  But why do we regularly see projects with  change requests before the business even sees a deliverable?

We might assume that we had the wrong stakeholders in the room.  Another potential cause could be that we didn’t do a great job collecting requirements. Certainly, there are projects where one or both of these problems exist.

But what I often find  is that the project is suffering from a case of “Discovery”.  More specifically, the business is stuck in Discovery and is not ready for Definition.

Discovery vs. Definition

Let me contrast the difference between Discovery and Definition. Put simply:

Discovery is the phase where the business identifies what problem to solve as well as a description of the end-state or goal of the project.

If Discovery defines what problem to solve, then Definition defines the path to the solution. In other words, the Definition phase focuses on how we are going to achieve the end goal.

An Example:

A small company is in growth mode, doing very well. At a recent Board-of-Directors meeting, the company’s management team was asked how they can continue their revenue growth over the next two or three years.

They currently develop advanced Word Processing solutions for Android products. Their solutions are customized to that platform and to take advantage of all the Google Android features, giving a rich experience on a mobile platform.

To increase revenue, they can choose to develop a complimentary Spreadsheet tool for the Android platform, providing the same, rich user experience and Google feature integration.  On the other hand, they can choose to create an identical Word Processor and user experience on other mobile platforms such as iPhone and Blackberry mobile devices.

There are probably other paths as well, all providing a path to their continuous revenue growth. At this point, we are “Taking a single goal and generating multiple ideas.”

Moving from Discovery to Definition

After much research and due-diligence, you conclude that the best direction would be to offer your current Word Processor and all of it’s rich user experiences on the iPhone and Blackberry platforms, solidifying your brand as “The Mobile Word Processor. Period.”

At this point, we have completed the Discovery phase because a decision was made on the overall goal. Now, it’s time for Definition.

In Definition, we  begin to define the path to that goal.  We start to define the key features that MUST be in the iPhone version and how we will replace Google Android features within the Apple iPhone environment.

Clearly identifying this  feature list is what is called Definition.

So Why Should We Care?

If you are trying to define the requirements for a solution, but your business stakeholders are still discovering what they call success, then you are destined for rework! And this will show up as:

  • A proliferation of change requests early and often
  • Slipped schedules, since they didn’t anticipate these discovery changing goals
  • Budgets being blown since they didn’t anticipate the increased costs associated with rework

Because they are still in Discovery, we can’t be sure of the right direction. Any step we take could cause rework that translates into budget and schedule variances.

My guess is that you could think of a project or two right now where the business stakeholders were probably not ready to define their system. And, most likely,  this “re-thinking” of their projects goals created a great deal of pain for everyone involved.

So What To Do?

When you are collecting requirements, or engaging with the business, if you believe they are not ready to define how the system will work, you need to “pop-a-level”.  I use this term when I want folks to take a step back, and take a different view.

So if you suspect you are being setup for a great deal of rework, then pop-a-level and ask your business team:

  • Do you have the right Subject Matter Experts who are knowledgeable and empowered to help define your needs?
  • Are you  still in Discovery? Are you unsure of what a clear definition of success is?

In either case, try to create transparency around the issue, highlighting the potential costs of continuing to move forward when the wrong stakeholders are involved or the goals are fuzzy.

Realizing your project is in Discovery is half the battle. No matter what’s ahead, this realization will enable to you stay on course and manage the project more effectively.

Have you experienced Discovery? Please share your experiences in the comment area below.

IT as Great Facilitators Part 4

What Great Facilitators Know About Estimating

IT-Great-Facilitator-4Last post, I shared an exercise that helped teams understand how to develop a plan that is manageable and achievable. I call this “Commitment Based Estimation”.  Now, I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to be effective at facilitating estimation sessions,  I’m going to discuss how to select the best person to facilitate these sessions.

I typically find that the team-lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who can allow the team to own the estimate.

When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to constantly optimize an estimate, then the team won’t feel ownership. This is not how to get a Commitment Based Estimate.

Similarly, when an architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.

Now, you may be thinking: Does this mean I can never challenge a team? It does not. What is does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.

For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now, you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Good Facilitators Can Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic.  I talked about this in a past blog called “Attitude of Estimation”.  As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered.  Project Managers can offer perspective on dependencies and resource availability.  The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects, and the database team also need to weigh in.  Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

Have you ever been in an estimation session where the facilitator was more of a hindrance than a help?

I hope you have enjoyed my 4-part series on facilitation. If you missed them, here are the links:
IT as Great Facilitators Part 1
IT as Great Facilitators Part 2
IT as Great Facilitators Part 3

In my opinion, there are way too many people who take the facilitator role for granted.

I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them.  A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

IT as Great Facilitators Part 3

Commitment Based Estimation

IT-as-Great-Facilitators-Part-3I want to tie together two concepts I have blogged about in the past few months. Specifically, how proper facilitation can help a team confidently develop a plan that is realistic and manageable.  This is what I call Commitment Based Estimation.  As a quick review, Commitment Based Estimation is an estimation approach that helps a team:

  • Develop estimates they genuinely believe are achievable
  • Feel ownership for their estimates
  • Treat these estimates as commitments and therefore honor them by managing to their plan

You can find my previous posts on this topic here:

Experiencing Why Commitment Based Estimation Works

I’ve used the following facilitation exercise to help teams understand some of the flaws with our typical approach to estimation.  This activity also demonstrates why Commitment Based Estimation can lead to much higher quality results.

I always do this 2-part estimation exercise in person and always with a group of people. Important: If you do this with others, be sure to state the following rules:

  1. You cannot ask any questions. Do your best with the information I give you.
  2. Write down your answer. This is important (especially when doing this in groups).
  3. You cannot collaborate or look at your co-worker’s  answers.

I’d like you to choose a shopping mall or large shopping center that is a typical weekend shopping destination for folks near your office.  The key is that it shouldn’t be across the street from your office, but requires a planned trip to get to.  For example, where I work, there is a shopping center called Oakbrook Mall, which is about four miles from my office.

Now here is the first step.  I’d like you to personally estimate how long it will take to leave your office, go to the shopping center, and find a store that carries designer sunglasses.  Then, purchase a pair of glasses with mirrored lenses for your spouse or other family member.  Then drive back to your office and drop off the glasses.  Oh … and one other thing… On your way  back to the office, please pick up an ink cartridge for your inkjet printer.

Now, I challenge everyone to come up with the estimate above. They each get about 90 seconds to come up with their answers.

The First Readout…

I then go around the room and ask everyone to read exactly what they wrote down as their estimate. It is important they use the exact words they wrote down. 60 minutes is not the same as one hour.

If you do this with a group, you will get all different answers. Typically you will get:

  • Someone who is  optimistic and says a very short time. From my office, they might say 30 minutes.
  • A  few folks who give a pretty precise estimate. For example 53 minutes, or one hour and 12 minutes.
  • Someone who  might be swagging it at one hour or “an hour and a half”.

That Was the Setup. So Now You Change the Game…

After everyone has done their readouts, I then say “great job” and explain that I want them to estimate again. However, this time  they have something to lose. I pretend that I am giving away an iPad or some other prize to the three folks who provide actual estimates.

So, I want them to redo their estimates. Knowing there is a prize at stake, they now have something to lose!

And Then the Fun Begins…

I now give the group another 90 seconds to redo their estimates.

If you actually created an estimate while reading along, I’d like you to take the opportunity to make it “more accurate”.  Pretend you could win a real iPad if you create an estimate that you can deliver on.

I then go around the room and ask everyone to give both estimates.  So again, here are some typical results during the second readout:

  • The person who was optimistic at 30 minutes says: My original estimate was 30 minutes and my new estimate is 42 minutes.
  • The folks with the precise estimates of 53 minutes either stay the same, or they may go up a little to 61 minutes.
  • (This baffles me.) There’s always someone that will take their estimate and actually lower it. They may go from 80 minutes down to 70.
  • And every once in a while someone “pads” their estimate and says “one full day”.

Seriously – the Lessons We Can Learn …

This seems like a hokey exercise. Yes – I am a hokey person 🙂 .  But let’s look at the real takeaways:

  1. When we did our first estimate, we didn’t take it seriously. The goal of the entire activity is to realize that if we have something at stake, we will actually estimate differently, and try to come up with an estimate we can confidently deliver on.So when our project teams are estimating, are they approaching this as the first go around?  Are they saying “You want an estimate? 53 minutes.”  Or do they understand there is something at stake?  They should re-think and verify that they can deliver on their estimate. Do they understand there is much more than an iPad at stake?
  2. We assume that an estimate should be as low an estimate as possible, even if it creates risk to delivery.When we estimate, are we so afraid of estimating for real world contingency and risk that we always estimate optimistically?  We probably shouldn’t pad to a full day, but we aren’t asked to make the estimate the “best case scenario” either.It should be an estimate that we all believe is achievable and can be managed to!
  3. When I do this in group, everyone wants to ask questions.  Is there construction?  What time of day are they going? Do they know what store has the glasses?  But as part of the rules, I say no questions are allowed.When they do this exercise, they can even be frustrated that they are being asked to create an estimate without knowing these answers. They think “How am I supposed to estimate this”?And this is exactly what happens in real life with our project teams!  It is the nature of our world that teams will always have some questions that can be answered and many others that cannot be answered. Yet, we still ask them for estimates that we can plan and execute against.

Commitment Based Estimating

Commitment Based Estimating is about helping a team deal with all three of these challenges. In my next post, I will talk about how proper facilitation can help a team deal with these challenges and deliver a Commitment Based Estimate that everyone believes in and the team can manage to.

Can you think of any situations where it would have been worthwhile to try this exercise before delivering an estimate?

IT as Great Facilitators Part 2

IT-as-Great-Facilitators-Part-IIIn my last post I talked about how facilitation is a key role, we each provide,  in the IT world. I also described the two pitfalls facilitators sometimes fall into: The Presenter vs. the Scribe.  Now, I am going to share two basic practices I’ve seen facilitators use to manage a room and deliver effective facilitation sessions.  These aren’t the only two recommendations, but I have found they help me personally manage some very strong groups.

First, the Check-in…

One challenge facilitators face is having a single person in the room dominate the discussion. There are two typical causes for this situation.

The first possibility is that others perceive the ‘dominator’ as having all the answers. This person has been around twice as long as us and is a genius. So rather than the rest of us spend 30 minutes trying to solve the problem, we can just let “Joe” tell us the answer now and finish up the meeting early.

The other possible reason for the ‘dominator’ is that the person who is dominating believes no one else has anything to add. They  shut down others by interrupting or attacking an idea before it’s given a chance to grow.

Both of these situations means that the room is in dire need of a strong facilitator. Someone who  can help everyone feel that their opinion matters and collaborate to achieve their desired goals.

One simple way to get ahead of this curve is a practice I call the “Check-in”.  At the beginning of the meeting, as the facilitator, you describe your understanding of the overall team objective and the specific goal of the session.   For example, the team objective may be planning the next company outing which is a picnic.  The purpose of this particular  meeting is to choose a theme for the picnic outing.

This part is simple enough. But then, you go around the room and ask everyone to  share their specific role related to today’s meeting. Now it gets trickier.

One person may have been part of the planning committee of past events and is there to bring their experience. Another person from HR and is there to help choose the theme and,  more importantly, to make sure the theme is appropriate,  professional, and compatible for special-needs employees. There may be an individual who is there to observe,  learn and support the team in activities like coordinating picnic vendors.

Because everyone shares their “role”, as a facilitator, you can clearly ask individuals to speak up, or prevent a ‘dominator’ from interrupting by explaining that “Jerry from HR” needs to chime in on any concerns from their role’s view.

As the facilitator, you aren’t trying to control the room or shut down any individual. You are simply asking everyone to both play their role and support others in their roles.

Next, the Chair…

This technique is useful when you  are  facilitating a group of people and standing in front of the room. Maybe you are at a whiteboard or easel, recording decisions or helping others capture ideas. The idea is that while you ares tanding up front,  the room of four to 12 folks are the working team.

When I am in this position, I always make sure to have a chair at the front of the room. If I am not physically at a table, I will have a chair just to the side of the whiteboard where I am standing. The purpose of the chair is to allow me to relinquish and regain control of the room.

For example, if  there is good discussion around a topic, even if it’s disagreement, I want to encourage this discussion and let the participants feel in control of the room. I will sit down at my chair and really listen to every word.

If at one point, things are getting off track or out of hand, or if the energy is getting low, I will stand up out of my chair and show my intent to start facilitating. I usually do this by raising a question.

This seems like a very small tactic, almost making you think, “Bob – are you serious?”  But if you are trying to lead a group, especially one that you don’t work with often, and need to make sure you are facilitating without confrontation, this is a natural way to control the energy and rhythm of the room. (To understand the importance of energy and rhythm, be sure to read my previous post on the role of facilitators.)

What has helped you facilitate more effectively?

These are just two ideas that I have seen effective facilitators take advantage of.  While there are other techniques I may share in future posts, I love to learn and hear about other approaches.  What are some of the effective tricks you have used to help lead and facilitate your team meetings?

IT as Great Facilitators Part 1

IT-as-Great-FacilitatorsIn the IT world, we all play the role of a facilitator.  Technical architects facilitate sessions for estimating and creating designs for their teams.  Project managers facilitate team and client meetings and make sure the team is on track to reach its goals. When Business Analysts collect requirements, they may facilitate large requirement meetings.  With so many kinds of facilitation roles, can we assume we know what being a facilitator really means? Do we, as  facilitators, recognize that this is a significant role we need to work at and manage in order to be effective? How do we make sure we stay  “within” our role as a neutral facilitator and not push our own agenda?

So you think to yourself, “Yes Bob, this is obvious. Of course I am an effective facilitator.” But let’s really test how effective each of us really are.

 

The Two Extremes of Ineffective Facilitation

When I have been a less-than-effective facilitator, I am acting in one of two extremes. I either go into “Presenter” mode or into “Scribe” mode.  Let me demonstrate these two extremes.

On one side, a facilitator may go into “presenter” mode.  Although their role is to facilitate a discussion (e.g. illicit requirements from business users or help a team arrive at estimates), the “Presenter” actually comes to the meeting with an opinion, specifically, a desired outcome. They are there to help others meet his or her agenda, rather than facilitate the room to develop its own opinions.  When a facilitator starts presenting, he or she does not allow others in the room  to collaborate towards finding their own solutions.  This shuts down the energy in the room. This also means the participants may not “own” the solution.

At the other extreme, a facilitator goes into “scribe” mode. When a facilitator is in “scribe” mode, it means that when he or she walks into the meeting, they sit and take notes and meeting-minutes but do not influence the dialogue.  This often allows others in the meeting to go off topic and start discussing points not related, in any way, to the objective of the meeting. Also, if someone is “checked-out” or “shut down”, there is no true facilitator in the room to make sure their voice is heard.

The Responsibility of a Facilitator

The best facilitators enable others to define, own and work in order to achieve their objectives. While the facilitator may bring an approach,  the solution is owned by the individuals they are facilitating.

A Good Facilitator:

  • Helps the team clarify and align on their objective and then facilitates the team so they make progress towards their objective.
  • Helps keep the group’s energy high, so everyone is contributing and feeling heard.
  • Keeps momentum or rhythm flowing towards the objective.
  • Does not change the team objective during facilitation. (Although they can help the team  change direction if the team believes it is required.)
  • Helps an entire group make progress towards its objective and makes sure everyone’s  opinion counts.

Additionally, a good facilitator is constantly taking the group’s temperature in terms of:

  • Energy in the room: Everyone is engaged, participating and making constant progress towards accomplishing their objective.
  • Rhythm of dialogue: The dialogue is flowing but stays focused on the initial goal of the meeting.
  • Focus: The meeting is staying on track and accomplishing its objective.  This can be tricky since the facilitator needs to balance discussion on side topics that are helpful to the objective, vs. topics that derail the goal. 

 

Are You an Efficient Facilitator?

Even if we  believe we are doing an effective job at facilitating, we may actually be playing a Presenter or even Scribe.  Here are ways we can test our effectiveness:

  • Are you directing conversations with your own agenda? Or, are you enabling the team to have its own conversations?
  • Are you making sure the team stays on topic and on track to meet its objectives?
  • Are you making sure everyone in the room is being heard, and no one’s idea’s are shut down? (This can affect the energy of the room.)
  • Did you leave your opinion at the door? A good facilitator helps get to a solution, not give a solution.
  • If you had not attended the meeting, would the team have accomplished the same result? (Maybe you are not being as affective as you think you are.)

When It Comes Together…

Simon Sinek recently shared the following quote:  “Don’t show up to prove; Show up to improve”.

When great facilitators lead meetings, they enable a dialogue that allows the room to make a decision. They do not abuse their role to force an outcome. Instead, they help everyone do a better job and accomplish fulfilling work. The room fills with energy and momentum that can’t avoid delivering results. When meetings feel this energy, you know you are leading the room and are an effective facilitator.

Do you consider yourself an efficient facilitator? Are there any other suggestions you can offer to help others meet their objectives?