Of course, there is no “right” a lot of the time.  In my classes, for example, I instruct and inform, but I also facilitate discussions about the options, and the students decide what’s going to work for them.

This brings me to the recent Facilitation Skills Workshop class I taught.  In this class, we learn about different facilitation techniques and then the students do the work; they actually facilitate each of the 12 sessions throughout the class.

Maybe you are like many of the students in this class who are terrified of speaking in front of groups. Their hands shake, they sweat, and some have a hard time breathing.  This fear is not unlike other fears and there is often a visceral response.

It is amazing to watch those folks who are terrified of facilitating get up in front of a group and, with some preparation, tools, and guidance, actually help the group accomplish a goal.  It is enormously validating- for them, the participants, and me.

The last session of the 12 sessions is one in which the facilitator brings the class to consensus on the top 5 characteristics of a good facilitator.  My last class came up with the following Top 5 Characteristics of a Good Facilitator:

1.     Neutrality
The facilitator cares that the group achieves their goal in the session, but they don’t care what the results look like specifically.   

2.   Preparedness
A facilitator needs to be prepared for their session. Facilitation might look easy, but it is hard work. Taking time to understand the group and issues, as well as practice the skills and techniques to be used make for a far more effective facilitator and one who will be much more likely to help the group achieve its goals.

3.   Energetic
A facilitator needs to be neutral, but that doesn’t mean they should be comatose.  Bringing some energy to the session helps keep people focused and engaged. 

4.   Clear idea of Purpose/Agenda
A good facilitator needs to start with a clear understanding of the goal of the session and the tools they might use to achieve that goal.  In short, be flexible, but have a plan. 

5.   Positive
An effective facilitator makes the participants want to achieve the session objective.  Even if it’s addressing a problem, a positive tone will encourage participants to own their part of the outcome.

It wasn’t necessarily the list I would have come up with, although those are certainly things we talk about in the class.  As I sat in the back of the room watching them come to this conclusion together as a group, facilitated by one of the students, it was an interesting and, in some way, teachable moment.  For me.

Facilitation Top 5 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

The close of one year tends to make one reflect on what has occurred in the past year and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

1. Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:

• Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
• Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
• PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.

2. Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

 In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

 3. PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.

 The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

 4. The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:

• Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
• Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
• In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.

5. BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:

• Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
• Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
• Post-project follow-up.We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.

 6. The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.

• Travel budgets.Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
• Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
• Collaboration toolshave made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.

 7.  “The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools.

7 Trends in Business Analysis and Project Management to Watch for in 2012 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Fortunately, we have a little meeting protocol where I work.  In our organization, you can’t schedule a meeting without identifying the objective of the meeting and the desired outcome.   At first, I didn’t think it would be difficult to get my thoughts around those things and document them.  (Did I mention I had a lot to talk about?)

But when it came to actually  spelling out the objective in the invitation, my fingers froze. I hadn’t really gotten much past “To talk about all the stuff I need to talk about.”  That, of course, left me with nothing to describe in the way of desired outcome. 

So I took my hands off the keyboard, put them on my forehead and started to think:  What is the purpose of this meeting?  Why should he take his time, that is, the organization’s most valuable resource, to meet with me?  What do I have to say that is worth his time to discuss?

The truth is, I did have a lot on my mind.  I was feeling overwhelmed and unfocused with more to deal with than I had bandwidth for.  I had ideas and thoughts about some things I was excited about and wanted to be able to address all of it, but I couldn’t.

The truth is also that I did not have a lot to discuss.  I just needed to know the current priorities of things on my plate.  My objective was to clarify my priorities, and the desired outcome that I needed at the end of our meeting was a list. 

Once this became clear, the meeting got a lot shorter.

How long ago was it that you attended a meeting with 3, 5, or 10 people without a clear understanding of the purpose and deliverable expected out of the meeting?  When was the last meeting you attended that got off track in the absence of a meeting objective?  How many meeting agendas have you seen that included extraneous items that wouldn’t have been necessary had a purpose been identified?  Most importantly, when was the last time you were sitting in a meeting that you might not have needed to attend if a clear meeting objective had been defined?  

The time it takes to be thoughtful about a meeting objective and desired outcome is not free, but it will always be cheaper than the time squandered in meetings without clear objectives defined.

So the next time you are inviting people to a meeting, consider identifying the objective of the meeting.  If someone were to ask you why your meeting is worth their time and organizational money, could you answer?  Maybe your objective is to get a decision about something.  Or identify options.  Or prioritize choices.  Whatever it is, define it first – before developing an agenda, deciding how long it will be, or whom to invite.

And then write down what it is you need to walk out of your meeting with, your desired outcome.  Maybe it’s a decision.  Or signatures of approval.  Or a list of options.  Whatever it is, write it down.  You’ll find your meetings are more likely to end on time because you know when they’re over – you’ve named it!

Try it.  But don’t expect to like it.  It’s a lot easier to just send an invitation to a bunch of people for a meeting about…you know…that thing we need to talk about.  

But once you have defined an objective, the rest of the meeting will become a lot more clear.  Your desired outcome will probably reveal itself.  Who really needs to be there will become evident – and will probably result in a shorter list of invitees than a meeting with no defined objectives.  Your agenda will begin to take shape and, again, probably be shorter than with an undefined meeting.

I ended up scheduling our meeting for 40 minutes, which is longer than we usually meet, but shorter than I initially intended to request.  I’m pretty confident it’s going to be a good use of organizational time and resources.  I think my manager is, too.

Is Your Meeting Worth the Time? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

A lot of project work gets done through informal, undocumented communication channels.  This is not only OK, it’s actually necessary.  Imagine if every conversation or information gathering effort we conducted required a documented plan.  The fact is a lot of good data can be mined from the water cooler and coffee klatch gatherings.

There are two types of this informal network: the grapevine and the rumor mill. I would suggest that while both are informal, undocumented communication channels and that they may include many, if not most, of the same people, they are significantly different.  The grapevine is an asset worth using; the rumor mill is something to avoid.  

How are they different and what makes one an essential part of a project manager’s communication strategy and the other a liability?  In my mind, it comes down to content and effect.

First, the nature of the content is qualitatively different between the two channels.  On the grapevine, information is  rooted in truth.  It may not include the whole story, but the information available is fundamentally true.  It is often a great source of information about prevailing attitudes, for example.  A project manager might tap into the grapevine to find out how people are responding to an organizational change of some kind. 

In addition, grapevine content is generally not specifically about individuals.  The vine is more about ideas and things, and less about who did or said what.

Content on the rumor mill, on the other hand, is highly specious.  Often the information obtained from the mill is patently false or so distorted by innuendo or editorializing as to be of little value. Of course, it’s not presented that way.  In fact, you can usually tell if you’re tapping into the rumor mill by a qualifying comment such as “My brother’s roommate’s cousin heard….”  The qualification serves the purpose creating distance between the information and the person spreading it; it’s a way of deflecting ownership for the information. 

Furthermore, the rumor mill is generally where you hear a lot about specific individuals and a lot less about ideas. Name dropping on the rumor mill is rampant – and generally not a place where you want your name mentioned. 

Still, it’s not always crystal clear as to which channel you are using based on content alone.  Effect is also important to consider in order to distinguish between the vine and the mill. 

The effect of the grapevine is positive (or at least not negative).  Use of the vine results in shared perceptions, level setting, or improved understanding.  The effect is not damaging or demeaning to others. When you are working the grapevine, you don’t feel uncomfortable about getting the information.  Grapevine conversations don’t inspire ducking into empty conference rooms to avoid being seen.  You come away from a grapevine conversation feeling like you could share what you learned with others without feeling like you violated a confidence or compromised anyone’s integrity.  You are comfortable with your name being associated with grapevine information.

On the other hand, the effect of the rumor mill is generally negative.  The purpose is really to provide cheap entertainment.  It’s the “You’re not gonna believe what I heard” factor.  When you are grinding on the rumor mill, you may look behind you or over your shoulder to see if anyone sees you.  These are the conversations that make you want to find an empty conference room or somewhere to avoid being seen.  Rather than about ideas or things, the rumor mill is almost always about people, and it’s generally not flattering.  The effect is usually that someone is shamed or demeaned or at least presented in an unfavorable light.

The savvy project manager will always make good use of informal communications channels in developing relationships with stakeholders, getting buy-in, managing expectations, and keeping the project on track.  The ethical project manager will know which type of informal channel they’re using, when it makes sense to use it, and when it’s best to disengage.

Grapevines and Rumor Mills – Assets or Liabilities? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I hear this from project managers on a regular basis and it always brings me back to one of the truisms in project management: The project manager is responsible for project success. 

This is concisely articulated in the Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition:

As the person responsible for the success of the project, a project manager is in charge of all aspects of the project including, but not limited to:

• Developing the project management plan and related documents
• Keeping the project on track in terms of budget and schedule
• Identifying, monitoring and responding to risk, and
• Providing accurate and timely reporting of project metrics

This is reasonable and I teach this to my students.  Yet, it’s not enough to simply declare that the PM owns the success of the project.  There are numerous qualifiers to project success resting on the PM’s shoulders.  In this article, I’d like to focus on roles and responsibilities as it relates to ownership for project success: Specifically, a project manager’s ownership for project success or failure makes sense only when others take ownership for their part of the project, as well.

For example, sponsors have to own their role on the project.  What the PM needs from the sponsor may vary depending on the project as I’ve written about in other articles. But it’s generally safe to say that an unsponsored project leaves a project manager destined for failure.

In addition, team members have to own their responsibility for the quality of the work they do.  (If possible, the PM can replace poor performers on the project, but that’s not always the case.)  Mistakes or errors in execution don’t necessarily doom a project to fail. Requiring that the PM take responsibility for the work of others, however, will eventually make it difficult to achieve any agreed upon definition of success. Team members have to own their work results – good and bad.  

Third, everyone needs to own their role in communications.  The basic communications model includes responsibilities for senders and receivers of messages.  As the sender, the PM can send clear updates, ask well-defined questions, request specific information, and provide timely reports as planned.  Stakeholders also have a responsibility to clearly acknowledge updates, definitively answer questions, provide requested information, and consume project report information as planned.  This is simple on the surface, but often exceedingly difficult in practice.

None of this is news.  Roles and responsibilities are essential and there has been plenty written about the importance of doing so early to alleviate all sorts of project problems.

Yet how often do project managers feel like they’re being asked to win at a game of tennis without someone on the other side of the net?  They willingly own the project success or failure, but it doesn’t feel like others have been as enthusiastic in claiming ownership for their piece of the project outcome.

Make no mistake: I am not looking for a way for PM’s to abdicate responsibility.  In fact, it’s the PM’s job to make sure everyone is clear on all aspects of ownership.  So, yes, the PM owns the success of the project.  And the next time you hear one step up and say “Yes, I will own the success of this organizational investment of time, money and resources,” make sure everyone waits for the follow up request: “And here is what I will need from each of you.”

Who Owns Project Success or Failure? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

It’s truly amazing to see 9-year-olds play hockey at the level that this team plays.  They skate on the ice as though they’re dancing on pavement.  They handle a stick with astounding skill.  They move the puck up and down the ice with agility that sometimes takes my breath away. 

It’s not hard to get caught up in this level of play and start cheering, shouting…OK screaming:  “Hustle!”  “Pass!”  “Move your feet!”  They are so good and they make it look so easy.  Fans sitting on the bench start to wonder, “What’s your problem? Shoot the puck!” 

Then after the game they come out of the locker room and you see them as…little boys.  With height not augmented by skates, bodies not donned in pads and equipment, faces not covered by helmets and masks, they’re just the little kids who like Saturday morning cartoons and still sleep with a favorite blanket.

If it doesn’t make you feel a bit silly for all the screaming you did, it sure does make you appreciate how good they really are.

Project managers don’t wear pads and helmets while managing projects and we don’t get a locker room from which to exit looking like a humbler version of ourselves to invoke appreciation for what we do.  

We do, however, get senior level folks to sponsor our projects and advocate for what we’re trying to accomplish.  We get access to resources, support to schedule and run meetings, and we may get training to help us do our jobs better.  We get teams of people and the wealth of organizational knowledge about what’s worked and what hasn’t on past projects.  So there may be stakeholders on the sidelines wondering, “What’s your problem? Deliver on time!”

Well, it’s tough out there on the project ice. Even when we get the sponsorship, resources, and skills we need to do our job, stakeholders are conflicted, organizations are in flux, and resources change.  While it may not look that hard from the bench, some days it’s amazing that we get consensus or momentum on anything. 

High expectations for project managers are a good thing.  But sometimes after a hard day, it would be nice to have a locker room where we could take off all the emotional and intellectual equipment we wear to get our job done and emerge for others to get a little different perspective for who we are:  someone just trying to get the project done for the benefit of the organization and everyone in it.

Hockey Players and Project Managers: Just Trying to Win was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

In any interview process, the key to being successful is to be prepared. However, we often get caught up with the one thousand and one things we have going on and we do not prepare as well as we should or (cringe!) we even wing it. Besides preparing a list of questions, one of the things that I do when I go into an interview is to have my checklist that helps drive my process. I used to struggle with being prepared until I related my experience with that of the hostage negotiator. Guess what? They have to be very prepared and they have a checklist too. Let’s see what their checklist looks like and then translate into BA speak to see if we can be more successful!

The hostage negotiator arrives on the scene and goes through their checklist (Credit to “howstuffworks.com” and “Ed Grabianowski” for the hostage negotiation checklist steps):

All questions “Q” are from the Hostage Negotiator. All answers “A” are from the Business Analyst and how you might respond.

Q What has occurred?
A As a BA you need to know all about what has occurred and what has not. Make sure you dive deep and understand the reasons for the project, the issue and/or the reason for why you are interviewing. There is a reason that your interviewee is holding requirements hostage and being difficult. Get a good layout of the situation so that you can approach it from a stable point of view. A perceived unbalanced approach could enflame the situation more. You must understand the context of the problem you are trying to solve.

Q Who initiated the call?
A Stakeholder analysis – it is NOT just for PMs! Determine who is driving the project you are on and why. The sponsor is your friend and should be your biggest supporter. Know what they want and why. Do they have a relationship with your difficult stakeholder? They might be able to help.

Q Time of occurrence?
A Does time really matter? Absolutely. Why was this project pursued at this time? What are the impacts of doing this project now vs. later? When does it really need to be completed? How does the timeframe impact your difficult stakeholder? It will certainly impact the questions you might ask during your interview.

Q What is the nature of the surrounding scene?
A Do you understand the political landscape of your environment and how it impacts the project you are working on? What about how it impacts your difficult stakeholder?

Q Police injuries? Suspect injuries? Hostage injuries? Other injuries?
A What relationships have been damaged in this “hostage” crisis? Have people, processes, data or systems been impacted, cutoff or disallowed as a result of this requirements hostage crisis? Will there be future injuries?

Q What kind of contact has been made with the suspect? When?
A What contact have you made with your interviewee? Did you just email them and set up a meeting? How well do you know this person? Did you reach out to them as soon as you knew they were involved? After the kickoff? Not at all yet? How you answer this question may give you insight as to why they are being difficult.

Q Is the situation locked in?
A Rarely have I come across a situation that is truly locked in. You may feel that it is locked in but as you explore what it means to be a good Business Negotiator (or Hostage Analyst) you will find that you can affect the outcome in a positive fashion. Remember, your difficult stakeholder wants something and there is always hope of influencing them.

Q Where are the suspects located?
A Know the dynamics of team and business. Geographically dispersed? Teleconferences not working? You may need to travel to more effectively to deal with the situation.

Q Where are the hostages located?
A More than likely the requirements being held hostage are locked up in the stakeholder’s mind and are not documented anywhere. However, do not assume that this is totally true as you may have access to materials that you assumed did not exist. Ask – you just never know. Maybe they are being difficult because they expect you to do all the work of pouring through volume after volume of mind numbing facts.

Q Where are the non-hostages?
A What is the state of other requirements elicitation and documentation? Is there a bigger problem here or is it just the one person? Make sure you know what you have and what you do not. Maybe there is another crisis just around the corner.

Q Where are the suspect’s observation points?
A What powerbase does your stakeholder have? Will they only operate from their home-base (their cube/office, their floor, favorite conference room, working from home)? What are they doing when no one is talking to them? Do they only have rules for you?

Q What firearms, explosives, and chemicals could be used/located on the site?
A What could your stakeholder do to sabotage your efforts if their needs are not met? What tactics will they employ? Do they have access and power to do so?

Q What is the description/profile of the hostage taker?
A Key stakeholder analysis. Do you truly understand your stakeholder? WIIFM – what’s in it for me? Do you know what’s in it for them? Is their effort to hold these requirements hostage unintentional or a directed effort to prevent things from moving forward? Are they in favor (accepting) of what you are doing?

Q What is the offender affiliation/public support like?
A Do you know who they influence and who influences them? Do they have support or are they left on their own? If a decision is not made in their favor will it affect you?

Goodness, there is a lot to think about in interviewing difficult stakeholders and this was all from the eyes of a hostage negotiator! And this was just the prep piece – there is also the techniques of the hostage negotiator and more that we can be inspired by and innovate. I realized early on that preparing was difficult and it took a lot of work. I also learned that when I looked at things a little differently I could introduce something new into my process which is an act of innovation. The result? My innovation = better preparedness = more “hostages” (requirements) released = requirements trash turned into stakeholder treasure!

Turning Requirements Trash into Stakeholder Treasure – Part 2 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

During his interview, he read some of his pearls of wisdom, one of which really resonated with me. He was talking about patients and their doctors, but I think it could be applied to any profession in which practitioners must understand the needs or “pain” of its patients, clients, customers, etc.

After absorbing what he said, here is how I would apply Dr. Loxtercamp‘s thoughts to project work, particularly business analysis:

• Clients (he said patients) can’t see outside their pain.
• Analysts usually can’t experience their clients’ pain.
• Relationships are the only way to span the chasm between the two and allow us to help solve the client’s problems.

I thought that was a simple, yet profound view of the challenge of discovering what people need, and it put some things into better perspective for me. What do you think?

Relationships Span the Chasm was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

One way to resolve persistent, negative thoughts is to do something to symbolize the elimination of the source of the negative thought and associated negative energy.  For example, you might write down your thought on a piece of paper and then tear it up or burn it to symbolize the destruction of what’s troubling you.  Psychologists call it ritual cleansing.

Projects can benefit from ritual cleansing.  Have you ever been in a meeting, for example, that gets derailed with negativity?  These meetings become dominated by people who just can’t move past what won’t work and why, or who’s wrong and how?

Instead of instructing people to be positive or trying to manage it with ground rules, give stakeholders a means of ridding their minds of ideas you don’t want derailing your session.  Institute a ritual cleansing of sorts.  Provide a “place” to dispose, drown, or bury all of those negative comments and ideas so you can keep your meeting free of distractions.  

Call it the Can of Can’t Do and place a can in the middle of the table and invite attendees to write their negative thoughts on a piece of paper, crumple it up and toss in the can.  Name it the Lamentation Library and tell people to “check in” their negative ideas (no checking out).  Maybe it’s a Cynicism Cemetery and plots are available for burial of unwanted thoughts.  The Pessimism Pool – it’s bottomless.  (OK, so you don’t have to go high camp with it, but you get the idea.)

Whatever you call it, designate a place for people to write comments that are negative or not constructive and allow folks to put their ideas in or on that place so they can get them out of their heads and get their heads in the real game of contributing ideas about what can be done and why it’s going to work.

This is not to suggest that all negative ideas should always be ignored.  In fact, sometimes it’s the skeptic that alerts us to risks we hadn’t considered.  But for a creative way to channel persistent and disruptive negativity, an occasional ritual cleansing may be just the thing your team needs.

Toss Negativity into the Trash with Ritual Cleansing was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Why do we do this to ourselves? 

Project managers know they should be getting input from the team on planning and the estimates for their work.  And they often do.  It’s what happens after that that’s problematic – namely, the input is ignored.

Why would we ignore the team, the people who know what it takes to get the work done?  Often because the answer they give is not what the customer or some other stakeholder wants to hear.

But who wins in this scenario?

The customer may think they do, but the team can only do so much, and if the project is late, the customer really isn’t getting what they want.

The project manager doesn’t win.  Their team is frustrated with them because any trust they might have had in the project manager is compromised as soon as they realize that the PM didn’t really want to know how long it would take.  In addition, the sponsor, customer, and other stakeholders lose confidence in the project manager because the deliverables are late.

The team surely doesn’t win.  And it only takes them until day 2 to realize that they’re going to lose!

If we ask someone a question, let’s ask because we really want to know the answer.  If we ask the team how long it’s going to take to get it done, let’s make sure we are willing to use the information we get, even if the answer isn’t what other stakeholders think they want to hear.

All stakeholders should have a reasonable chance of looking good past day 1.

On day 1, we look great. It’s day 2 that kills us! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog