Subscribe via RSS Feed

Tag: "business"

Winning with “Project SD”

Winning-with-Project-SDEvery team needs a process they can embrace because they know that process will get them to the desired result.

Announce Changes and Avoid Wig-Outs

breaking pencilIn previous posts, I have discussed best practices around Change Control. Or, maybe I should say “lack of best practices” since so many organizations either fail to follow a defined process or simply don’t have one.

What Taking-a-Hike Can Teach Us About Business

Hiking in autumn forestSomething Special…

This week I have something special for you. A guest post from one of my best friends. Dave Katauskas regularly shares insights that  make a huge impact on a team’s performance and success.  The story below has changed how he and I make choices within our daily work.

So, without further ado, I hope you enjoy the following blog post as much as I did.

Have I got a story for you!

Recently, my friend, we’ll call him “Bob”, and I decided to hike on the Ice Age Trail in Wisconsin. This was in preparation for our bucket-list-goal of walking a portion of the Appalachian Trail.  We knew any hike would be a challenge merely because we were non-active desk jockeys, 50+ pounds overweight and past middle-aged.  If you’ve ever seen the “before and after” photos in most health diets, we would be in the “before” picture.  I believe that sums it up.  Yet, we were determined and eager to get started.

Let’s get going!

On the first day of our 2-day hike, we set out on the Ice Age Trail to explore the wilderness and just enjoy ourselves.  We saw many great sights and regularly rested with food and water from our backpacks.  It was a great day with perfect weather.  All of the elements indicated that this day would run flawlessly.  In an eerie sort of way, this was strangely similar to the optimism and energy we have when starting a new and exciting project.

Knowing that this first leg of the hike was only a day hike, at some point in our journey we would need to turn around and track back to our car.  The morning went well. We felt strong, full of energy, sharing a great time on a beautiful day. The morning was going quickly and before we knew it, we reached the five mile mark. It was just after lunch that we started to think that turning back at this point would be smart. The second half of the hike would probably go slower.

After looking at the map, there was a ridge ahead that would provide some interesting views and a shelter.  Feeling physically able and still eager, I suggested that we squeeze in a few more miles before turning back.  Bob had a gut feeling that we needed to turn back because we may be reaching our physical limits.  He’s older and more out of shape. Of course, he was also being risk adverse. We all have a Bob on our project!

We clearly weren’t in agreement, so we discussed it a bit.  But without the definitive proof that we were actually reaching our limit, we decided to press on. His version of this story is that I convinced him to press on. We agreed to turn back at mile seven.

Around mile six, the path changed to a steep incline. I mean a painful, slow, incline.  But we made it to the top and to mile seven.  We felt great at arriving at the top of the ridge and rested on the trail near the tall grass.  Unfortunately, the view wasn’t as spectacular as we had imagined.  In fact, there was no view at all except for tall brush and grass.  But we still felt great at making it to mile seven!

So we took a break and decided that it was time to turn back.  The first seven miles were great so the next seven should be equally great…right?  As you’ll read later, we were oblivious to the fact that we were just short from the real “point of no return”.

It’s really not that much farther…

Well, about two miles into the return trek, we realized that we were out of water.  In addition to that, our legs and feet were starting to become very fatigued and sore.  But press on we did, not that we really had an option.  So, another two miles later (that’s 11 miles total for the geeks doing the math…like I just did) we were now becoming worn out. The storm clouds started rolling in, the wind was picking up and our flawless day was no longer looking so flawless.  We now had as additional sense of urgency to stay out of the impending storm.  Yet, we still had about three miles to go.  We saw the coming gloom, we still had plenty of trails in front of us and we were in pain. Talk about a “Death March”! (Have you ever experienced a software project similar to this?  Doesn’t this really sound like the beginning of a death march?)

Houston, we have a problem

The next mile became a struggle as our bodies were not actually equipped to deal with the demands which we had placed upon them.  This next mile was truly indicative of what the final two miles had in store of us.  Our legs started cramping, each step was actually painful and we were thirsty.  We limped along, well aware of each and every step. We genuinely weren’t sure if we would make it back to the car without some assistance.  (How many times have we committed to more than we can successfully handle?  Or actually know what we are really committing to?  On the plus side, we did know that were very close to needing to ask for help.)

And then it happened…

It became apparent to us that our short term view of what we thought was feasible became a decision that ultimately created pain, anxiety and the possibility of failure.  To add insult to injury, it started raining. (The “death march” continues)

After a long while, we finally reached our destination and found a covered bench.  We sat for a few minutes, then headed toward the car; a distant 12 feet away.  Limping and cramping is what I remember mostly.  After what seemed like an eternity, we walked from the bench to the car.  Now we just needed to get in.  We somehow managed to hold back the man-tears. Well, at least I did!

The residual evidence was apparent by our pampered and ginger walking around the office over several days.  A trip we’ll never forget!  (I’ve certainly been on projects where we limped across the finish line). Yes, pain is certainly one of the best teachers.

How we changed our views

A few weeks after our hiking experience, we were able to reflect again upon our journey and we noticed similarities around how making decisions for short term goals, or decisions based on lack of insight, can have significant effects on long term outcomes.  The decision to continue after mile five was clearly a bad decision.  We talked about the moment, that specific choice, which led us to continue on.

Then I thought about all of the bad decisions that I’ve witnessed and made on project work. But instead of the conversations centering on making a bad decision, we would state that it was just poorly executed. We would never challenge our decision approach or conclusion.  For this hike, our execution was fine; the decision was bad.

We then started discussing some of the decisions that we’ve personally made in directing business objectives and how some of those decisions created pain for ourselves and others.  And, in some cases, it established additional barriers for corrective action.

Our take away…

So, when making business decisions today, I now ask “how can we prevent this from becoming our 14 mile death march?” and “are we just kidding ourselves?”  I was actually able to put this into practice one day when our leadership group was discussing strategic staffing.

We knew that a decision to handle a short-term, non-bulls-eye opportunity would certainly hurt our capability to engage in an on-target opportunity in the future.  So, we had good discussions around that topic and looked at the varied perspectives with our eyes wide open.  We stuck with the strategic goals in spite of a small immediate win.  And since then, we’ve been able to apply that same concept to other growth challenges.

In addition to all of that, Bob and I have since hiked again.  This time, it included a change in our behavior, thinking and knowing our real capabilities.  It was a more pleasant experience.

So next time you have a tough choice and everyone is debating an approach, consider you may be at mile five of your hike, and sometimes, it’s better not to push the limits … because you’ll feel the pain for quite some time afterwards!

Eliminating the “Black Box Effect”

Eliminating-the-black-box1Regardless of whether you are doing iterative development or use waterfall methods, you may be struggling to get agreement on whether a delivery team is on track or falling off expectations. This blog covers techniques that can help business and technology teams agree on how to track progress of a technology project.

The Black Box: is any comparatively small, usually black, box containing a secret, mysterious, or complex mechanical or electronic device.

One of the key complaints of a pure waterfall development approach is the reality that a project may not show any results (or provide any feedback) until the software is completely finished.  In other words, the business really has no idea if the project will meet their needs or is on schedule until the software is delivered.

For example, we start a project in January.  It may take through February for initial business architecture and design to be completed.  It may take another month or two before software is actually being developed and delivered to the testing team.

The business may not get any visibility into working software for six months or more.

This is what I call the Black Box Effect. We need to find a way to eliminate this effect and have an agreed upon approach to determine whether a project is on track or not.

The benefits of an iterative approach

There are many reasons an organization may choose to move to an iterative development model such as Agile or Scrum.  One of the more important reasons is to gain more frequent feedback on whether what we are building meets the real business need.

Are you  tired of the business saying, “What did you do to me? I thought we were going to have this done.” And are you tired of hearing yourself say, “Well, I thought we were going to have THIS done!” If that’s the case, then you are obviously not in agreement and have a “visibility” problem.

Visibility isn’t a project plan!

Visibility isn’t a project plan that tracks progress. Visibility is agreeing that the business can get access to completed functionality. Visibility means the business can see how the software being developed will help them achieve their business objectives defined earlier in the process. If they can get visibility into that on a regular basis, then we can agree on whether we will be able to “high-five when the project is done.”

Not only do we need to provide the business visibility on progress, but we need to allow the business to re-evaluate their priorities based on the progress seen. Consider this a feedback loop, allowing development teams to constantly re-evaluate and tune their approach.

I use three key opportunities to provide visibility and get feedback from the business: QuickPeek, Showcase and Release.

QuickPeek

At the end of each iteration, the team should be able to show software that has been developed and completed through unit-testing. The software may not have been put through functional testing or even integration testing, but it has been completely unit tested. There may still be remaining defects.

We encourage the business to review each iteration’s results and make sure we are on track with their expectations – even if the code is not yet packaged for deployment or completely system tested. Remember, the QuickPeek  is typically informal and just to show the iteration progress.

Even in a Waterfall process, you should be able to start identifying key components being developed every two weeks that can be “viewed” by a business stakeholder for feedback.  Maybe some deliverables will take a week while others take up to three weeks.

I believe you can introduce a QuickPeek on a regular basis without too much intrusion into your current corporate process.

Showcase

When a release is going to take six or more months, there is value in planning a Showcase.  This  is a formal review of a set of features or system components.  Functional testing is typically complete and it shows complete business scenarios or processes at work.

However, it typically is not ready to be deployed like a release.

The purpose of the Showcase is to demonstrate the functionality of a complete component to a wider group of stakeholders. It is also used to celebrate progress and create a common vision around the new solution.

Even in an Agile world, you may not be deploying a release until Iteration 10 or 12.  Therefore, there probably is value in creating a Showcase around Iteration 4 and Iteration 8 to provide greater visibility and market the progress you have made.

Eliminating the Black Box creates Visibility

I hope these techniques can help even a waterfall shop create greater visibility and market the progress the team is making. Throughout the development process, it allows the business and I.T. to develop a common view of progress and decide whether adjustments need to be made to the final product.

Do you incorporate all of these techniques? If not, what are the obstacles?

Alignment: Antidote to Rework

Alignment-Antidote-to-Rework1In my last post, I introduced the Getting Predictable℠ Best Practices and explained  how they are designed to set project teams up for success “from the start”.  These practices cover three areas: Alignment, Commitment and Visibility.

Now I am going to dive deeper into the  concept of alignment and why it is critical to reducing rework and helping any team (not just IT) meet its  expectations, each and every time.

What is Alignment?

With technology initiatives, the goal of best practices around alignment looks like this: The business stakeholders all have a common answer to the question, “What is success for this project”?  In other words, they have agreement when the team can stop and everyone can  high-five because they all got what they needed.

At the other extreme (and this is the problem we are trying to solve), we don’t want the business to say to the team: “We have a really critical schedule, so you guys start and we’ll figure it out later”.

Why is it so important to focus on aligning the business stakeholders?  Isn’t it more important to focus on aligning the technology team to the business? No it is not more important – and this answer is of huge importance!

The technology team can’t align to the business goals if the business doesn’t agree on those goals! In other words, if the business isn’t in alignment, how can a technology team align?

What are they aligning to?

More importantly, a lack of alignment on the business side means there is almost certainly rework ahead for the technology team.  As the business goes through the process of coming into alignment, the IT team needs to make constant adjustments.  Sometimes in small ways, but other times the change can be significant and involve removing or changing an entire component of the solution.

When was the last time rework got extra schedule or budget?

This blog will cover those Getting Predictable℠ Best Practices that focus on helping the business get alignment on answering this question:  “What is the definition of success for this project?”.

Alignment is a great idea, but I don’t think it can work for me

Now you  might be thinking: “I can’t get my business folks to a single meeting, let alone get them to agree!” In future posts, I will share best practices that have worked for me. They don’t all work, and they don’t apply to all situations, but I have come to rely on these simple practices to get the results I am looking for.

And there is a huge side benefit.  By helping the business come into alignment on the key objectives of a project, I end up building a new level of trust in my relationship with the business team.  This truly was a pleasant surprise.

You will find some past posts, as well as future posts that focus on key areas such as:

  • Facilitation techniques
  • Aligning the business when they are geographically distributed
  • How to align interested parties that aren’t decision makers
  • Being adaptive to change and protecting alignment
  • When a lack of alignment is ok

So what do you think?

Do you believe this is a problem in your world?  How bad is it? I’d love to hear examples in the comments below.  If you don’t have this problem, why?  What do you believe you are doing right?

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

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?

It’s 10am and the Requirements Session has Started… Do You Know Where Your Business Team Is?

Requirements-Session-Has-StartedWhen sharing Getting PredictableSM best practices, specifically around requirements definition, a common question that comes from I.T. management,  Business Analysts and Project Managers is:

“How do I get the business to come to the table? How do you get the business folks to commit to the time needed to properly collect requirements for a project?”

 

Most business folks are very busy, but the underlying problem is more than just time management.

Many business users feel it’s a waste of their time. It’s truly annoying to have to tell the “tech folks” requirements. They’re gonna get it wrong anyway.

And you can’t really blame them.

Let’s picture their world:

You’re working 8+ hour days doing your full time business job. You have plenty of regular weekly meetings you go to, some that are a waste of energy.  Now your boss tells you the tech team wants to meet to ask: “How you do your job” or “What features would you like in the new system”.

You show up and as you start sharing your thoughts, they keep suggesting a better way. At times, you hear things like “what you are asking for is very complex – or is undoable”.  A bit frustrating, but you trudge on.

The Requirements Sign-off

Then the business users are asked to read the requirements and sign off.

First off, some of the documents read like a technical manual for a Sears Washer and Dryer explaining how to disassemble the drive motor and replace some fan belt so your washer doesn’t make that whining noise anymore.  The part of the documents that do make sense to you are sort of right – but you’re not sure how much effort to spend to get it 100% perfect.

This might be a little exaggerated, but go ask your business user to read the above paragraph and listen to what they say.  Many will surprise you with their feedback.

Over the next couple of months, the I.T. team asks a few clarifying questions here and there and some of the questions have no resemblance to your original requirement.

When you get the new software, it isn’t what you asked for.  And the technology team is combative. The I.T. team is saying your requirements were wrong and that’s why the system doesn’t work properly.

Surprised?

Hmmm… Why in the world would the business want to experience this?

While  a little exaggerated,  I have to admit that over my career I have heard business users say this.  There is some truth to these remarks and they represent obstacles for our teams.

That said, there  are some simple ways to get the business to check in and truly get passionately involved. Here are some quick ideas to point us in the right direction:

  • First and foremost, Listen.

The joke I share with my technical leads is that “Before we might say ‘no’ to a particular feature, at least listen to their entire request. Then you can say ‘no’”.

And yes – this is intended to point out that all too often, we start compromising a requirement because we know the business better, or their way takes four weeks to do and tweaking the requirement can get it done in one week with an off-the-shelf product. We need to listen to their full need and the “why”.  Then you can be a partner and offer them options.

This brings me to the second suggestion.

  • Give them Options.

Don’t simply tell them the system can’t send the data to all 123 data centers and get responses in under 30 seconds, assimilated in 14 languages and then graphed real time.

Explain to them this one requirement may take two years and 24 people to pull off and that if they would be willing, here are two or three alternatives that may work and would take two months to get completed. Ultimately it’s their budget and their choice on schedule.

They will feel less like something is being “done” to them and more like you are truly trying to help them through this process.

  • Finally, Give them what they asked for and Quickly.

What I mean by this: If they asked for a special screen to do a quick side calculation, and you see they have energy, create a quick mock-up or even a prototype and ask if this is what they had in mind. Make sure you don’t embellish. Give them exactly what they asked for.

If you have a great idea, then show them a second version of the mock-up after you showed them theirs. Let them buy into it.

In an iterative world such as Agile, it is part Agile to quickly turn around a requirement for user feedback.  Even in Waterfall, you can create anything from paper prototypes (see my previous Lo-Fi post) to a wireframe or real code for those scenarios that the user was really passionate about.

Before you know it, you’ll need a bigger conference room for your requirements meetings because all the different business stakeholders will want to come and give you “their” requirements. They won’t trust their colleagues to represent their opinion.

Do you have issues getting the business to come to your requirements sessions? How do you deal with it?