I just established a war room for the beginning of a new project.  In its simplest terms, a war room is a workspace dedicated to a collocated project team, enabling team members to work together to quickly create a solution to a business problem or address a business opportunity. 

 Over the years, I have been responsible for many war rooms and I have been collocated in war rooms run by other project managers.  I love a good war room.  When done well, I think a war room contributes to better work, shorter cycles and a really positive team experience.  When done poorly, a war room is just another meeting space. 

 This got me thinking about my own personal “war room best practices”, which I will share here.  I would love to hear your best practices on this topic, if you have any you’d like to share. 

 Ground Rules

I hate to start off a fun topic with something as pedestrian as rules, but when you have a group work space, it’s best to begin with a clear understanding of boundaries. 

 In my experience, the biggest issues are usually around non-project discussions in the project work room.  I always have a rule that anyone can stop by the War Room to have a quick discussion with a project resource, but those discussions cannot last longer than 5 minutes.  This is clearly stated in the room on a WAR ROOM RULES poster, and I have a kitchen timer nearby just for that purpose.  It not only protects the other folks in the room from having their space co-opted by a non-project meeting, it actually helps the project resource from continually being pulled back into non-project work that has been reassigned (successfully or not) to someone else. 

 The other way this issue rears its ugly head is in cell-phone conversations.  We have all worked on a team with someone whose spouse or children call every 20 minutes.  I have a rule that there will be no non-project related telephone conversations in the War Room either.  If you need to take a personal call, step out of the room.  If you have a teleconference that is not related to the project, attend from another location.

 Another idea is to post “core work hours” for the project room, during which all resources will be in the room and available.  Not only does this clear the way for collaborative work, it lets resources set the expectations of their managers, peers and customers appropriately. 

 Creature Comforts

I think a War Room ought to be a pleasing place that people are excited to be assigned to.  Food is one of the easiest ways to turn a work session into an “event”.  I always provision my War Rooms with snacks (both healthy and unhealthy) to send the message that “you, and the work we are doing here together, is special, not run of the mill or routine”. 

 I bring in lunch and/or breakfast on deadline days to send the message that the time and attention of the people on the project team is so important to the success of the project that I don’t want them worrying about finding something to eat.

 Don’t forget about other things that contribute to a comfortable work space.  Keep the area clean.  Open a window or bring in air fresheners.  Do what you can to create a temperature that is comfortable to most of the people most of the time, and bring in fans or heaters for people who need them. 

Depending on the people in the room and the work underway, I have played music in the room.  In one of my War Rooms, we worked European business hours for three weeks one December, requiring us to start our work day at 2:00 am every day.  We played Christmas music and had bagels every morning to get the day started. 

 On another project we had a huge, all-hands-on deck “cut and paste” effort to get some data normalized into a giant excel spreadsheet. Because our customer had dropped the ball on it, my team undertook this really low-value but critical task.  The team worried that we wouldn’t be able to stay awake during the 8-12 hours it would take to complete the work.  So, I streamed a Law and Order: SVU marathon through the projector and we ordered pizza for lunch, and everyone talked about how it reminded them of cram sessions they endured in college.  This tedious task turned out to be a team-building effort because we all pitched in and made the best out of a bad situation. 

 Visuals

People are stimulated by graphics and visual representations so you should have some project artifacts on the walls of your War Room.  Not only can these be appealing and information for the people on the team, they can be a great way to share information about the project to the rest of your organization. 

Use the space you have to guide project discussions and underline project information.  A blank wall becomes a living flow chart with painter’s tape for swim lanes and sticky notes for process information.  You can easily make and print calendars and tape them around the room, although I prefer large dry erase calendars that can be used for planning and what-if scenarios. 

Testimonials, customer artifacts (anything with a logo) and company information can be used to keep people focused on the long term goals of the project. 

Then take all that useful visual information and hold a project “Open House”.  Send out invitations and invite people to come in, visit with the team, and see what’s going on in the work room.  Make it a fun event with food (ice cream social, anyone?) and door prizes.  Tying this in with major project milestones can also serve your change management and communications plans as well.   

 Customs

Finally, it’s hard to create traditions, but you can certainly recognize trends that can turn into War Room Customs. 

 For example, I worked with one gentleman who would say “Big brain on so and so” whenever someone had a great idea.  Eventually we would all say it to each other to recognize a good idea – “Big brain on Bob today!”, so I went to a teacher’s supply store and bought a… big brain.   Then when we wanted to recognize someone, we would say “Big brain on Beth” and toss Beth the big brain.

 At another organization, we used the word “sacred cow” quite frequently, so I bought a small, stuffed cow that we would hand around the table when we wanted to challenge someone to think differently about and idea they demonstrated a stubborn loyalty toward.

 These are some of my best practices, and I am eager to hear yours.

• The first iteration will almost always be a bust. The team is learning how to estimate their work an entirely new way with relative story points, and assessing how much work can be fit into a preset allotment of time. It is very typical for the team to overshoot and not get all the work done that they carve out for themselves. It usually takes 1 or 2 iterations for the team to gauge their velocity or number of story points they can accomplish in an iteration. Only then should an attempt be made to do any type of release planning so you will know how many iterations it will take to achieve all the functionality desired in the release.
• One of the benefits of agile is the flexibility is offers around scope change between iterations, but the cardinal rule is that once the scope of the iteration or sprint is set, no one disrupts the team. That means no high level stakeholders pulling rank and diverting team members to go work on another project. This is one of the reasons the iterations are kept short – no more than 30 days usually, and sometimes shorter, so that the team comes up for air frequently to entertain changes. An obvious issue with this design is the case where the same team must support bug fixes as well as new feature development. One solution to this is to build into every iteration some buffer stories for unknown bug fixes that can be assigned if critical bugs are logged during the iteration that must be addressed by one of the team members.
• On an agile team there is no traditional command and control model. There is no traditional project manager role. The scrum master has no direct authority; he/she is more a facilitator. The team is self directed and self organizing. The team members assign themselves work from the waiting tasks list. This is a hard one for many managers to swallow. They believe that without a supervisor to crack the whip, the team members will have no motivation to work. Most scrum masters find the opposite is actually true. If anything, they have to coach the team to be less aggressive and not bite off more than they can chew. When held accountable for their own work team members will most often rise to the occasion and try harder to prove their worth and value. Where scrum masters do add value is to coach team members to direct their effort towards completeness of fewer stories rather than near completeness of more stories. The only stories that can be demoed at the end of an iteration are completed stories.
• Agile means fewer artifacts. There is a product backlog containing user stories, iteration backlog, and some burn down charts. Typically that’s it. If there is anything more, it is due to organizational culture requirements. As the engineering progresses and conversation happens between developer and business, validation requirements (which is where typical detailed business specifications would be captured) will be developed and captured as part of the test driven development process – which is where it should be to have any real utility. How often have you really ever looked at those extensive business requirement documents (BRDs) after they’ve been developed? Certainly by the time a new project is launched, they are usually outdated and if they are even archived anywhere, they are usually never looked at again. All that effort wasted. So spending the effort getting the right people talking in the first place and documenting where it needs to be won’t result in a lack of valuable documentation, because all those BRDs were never truly valued much in the first place.

Spend time making sure your management really understands how the new agile team will work with each other and with others in the organization and what is expected of them before you start. They will appreciate the education and it just might keep you from becoming the next Dilbert cartoon.

─ Online Poker estimating tool: (Free from Mountain Goat Software: www.planningpoker.com ) when teams are performing relative story point estimates and they are all in the same room, they frequently use poker cards. After discussing the story, each team member chooses the card with the number of points they believe the effort represents and all members hold up their card at the same time, so that no one is effected by anyone else’s vote. When someone is not in the room, this requires a different tool. There is an online version of the physical cards where members select their number and only when all members “playing the game” have made a choice, does the moderator release the selections so that everyone can see the numbers chosen.
─ Livemeeting, Gotomeeting, Webex, or other conferencing tools: tools allowing virtual meeting and presentation of materials or system demoing, remote desktop sharing, etc.
─ Skype, other teleconferencing tools: to allow virtual “face to face” interaction
─ Instant messaging: to allow texting/chatting between team members. There should be team covenants regarding responsiveness to IM, email, phone calls, and other forms of virtual contact in the absence of physical contact.
─ Sharepoint, Google Docs, Basecamp, other collaboration platforms: a strong collaboration platform is needed for storage of notes and design documentation. Team calendars, ground rules, conventions and protocols, time zone information, burn down charts, product backlogs, and other team artifacts can be stored here.

While some thought needs to be given to how to divide work and include remote teams or remote participants of a team, many organizations are successfully utilizing agile methods on virtual teams. As with any project any time, the key is in developing creative and consistent ways to communicate among the separated team members.

Processes:   The primary scrum processes allow for grooming of the product backlog or clarifying the complexity by specifying effort factor (story points), grouping work from the product backlog into work iterations, defining and estimating technical work tasks for the work iterations, and packaging completed outputs of the work iterations into a working release product.  Below is a breakdown of the different scrum processes along with their descriptions and analogous waterfall counterpart.

Meetings:    Since frequent feedback is the hallmark of agile, the scrum meeting are the settings that facilitate some of the above processes, as well as allow for frequent status during the work intervals or sprints, and provide the vehicle for the customer acceptance and process improvement.  Below is a table that describes the major scrum meetings, descriptions and their waterfall counterparts.

 Artifacts:  Artifacts are sparse compared to a typical waterfall methodology. All work “to do” is tracked on the product backlog.  Work “left to go”  is tracked on one of 2 types of burn down charts and are meant to show progress to the organization.  Business requirements will seem sketchy in agile as compared to waterfall since preference is given to conversations amongst members of the team, and verification through acceptance criteria and demonstrations.  Below is a description of scrum artifacts.

 In scrum, relative estimation keeps the estimation process intuitive and non specific.  It’s done in group session with the entire team where everyone “votes” on their number all at once to keep voting independent.  The relative story points assist the product manager in backlog prioritization.  Sprint planning makes up the rest of the planning for a 30 day period.  This is where the detailed task decomposition and hourly estimation occurs.

Once a sprint is planned, work is executed and monitored in the daily standup meetings.  Issues are tracked in the Sprint impediment log.  Progress is displayed to the organization in artifacts such as the sprint and product burn down charts.

At the end of the sprint, the work is verified and accepted or rejected in the sprint demonstration meeting.  Then the sprint processes are reviewed and suggestions for improvement are made in the sprint retrospective, before reprioritizing the product backlog if necessary and beginning a new sprint.

I first became interested in agile when I was leading technology teams and consistently struggled with the standard waterfall challenge of getting accurate, complete, well understand and well documented business requirements for long software development application projects.  Once we felt like we finally got things “nailed down” and began design and development work, requirements would change before we could deliver the first release.  The agile methodology is a natural solution for this.  I began my own course of self study, networking and training, and eventually acquired a scrum master certification.

To understand the principles of any of the flavors of agile methodology (and there are several), you need to first understand the agile manifesto, developed by the original set of agile founders:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Scrum happens to be one of the most popular types of agile and derives its name from a daily standup meeting called the scrum meeting, involving the team and the facilitator who is called the scrum master.  Below is a discussion which breaks down some of the important roles used in scrum and compares them to their analogous counterpart in a waterfall methodology. 

Roles – there are only 3 officially recognized roles on an agile scrum team:

• Product Owner – The product owner is a member of the scrum team and is responsible for what the team builds and for optimizing the value of it.  He/she owns decisions and risks regarding what business stakeholders want.  He/she defines the features to be produced and decides on release date and content, and determines feature priorities.  He/she can change features and priority between sprints.  He/she negotiates acceptance criteria for work results with rest of team
• Scrum Master – facilitates process and keeps things moving.  He/she manages the internal dynamics of the team including the relationship of the product owner with the rest of the team.  He/she enforces the scrum framework.  He/she ensures full team involvement in all meetings and keeps everything visible, including “radiating” information to the larger organization.  He/she shields the team from external interference.  He/she advocates improved practices.  Very important:  He/she facilitates, but does not manage.  The scrum master has no official authority over the team.  He/she cannot assign work to the team.
• Team – This is a small (7 +-2 member) cross functional group who are responsible for the work they agree to take on during the work period called a sprint.  They are a self organizing unit – meaning they assign sprint work tasks to themselves.  They negotiate the work of the sprint with the product owner.  Along with the product owner, they demo the work results to the stakeholders.

The product owner is analogous to a business analyst, product manager or sponsor in a waterfall methodology, and the team is similar to any team anywhere, with the exception of the self organizing part.  That’s a little loose-y goose-y for a lot of management teams to get used to.  Frankly, what I’ve seen in a lot of companies I’ve networked with is a gradual approach to this, because as much as this sounds like a great goal, in companies that have been highly command and control, teams have to get as used to it as the managers themselves do.  The scrum master could be similar to a technical team lead or a technical project manager in some organizations.  What is strikingly missing in this model is the overall project manager him/herself.  The traditional, all controlling, project manager doesn’t really have a direct correlation.  To find a home in an agile practicing organization the PMI style project manager has to make some decisions.  For individuals with a more product oriented, business slant, the product owner might be a great role to assume.  For the more technically minded, the scrum master role might be a better fit.

One of the most intriguing differences between agile and waterfall and what in my mind makes agile so compelling is in the area of scope control.  In the waterfall methodology we go to great lengths to define the scope of the project in as much detail as we can all up front, and then protect that scope.  We define a rigid scope change process which acts as a deterrent to anyone who wants to introduce changes to the work that we already have a complex tangle of design plans around, because of the cost and pain of implementation when you work on everything all at once.  With agile the notion of scope control is virtually non-existent, except within the context of the short periods of work, called sprints.  This is by design.  This is to allow and even encourage the product owner to be flexible and change their mind in between sprints as the business sees the results of work and reacts to it; and as events in the business change. 

In a nutshell, product features and all other work are maintained in a document called the product backlog, in single threaded priority by the product owner.  The team determines “chunks” of that work off the top that they can perform in time boxed periods of work called sprints (usually 30 days).  Once a sprint starts, the scrum master insures that the scope of the sprint does not change.  At the end of the sprint the team and the product owner jointly demo the work that has been completed to the business stakeholders.  The product backlog is reprioritized if necessary by the product owner and another sprint is started.  Sprints are repeated until enough work is completed to comprise a release.  Sounds simple huh?  Well there’s a little more to it than that.

In my next article I will discuss the small set of artifacts, meetings and processes involved and discuss what they compare to in a waterfall context.

In many respects, the successful planning and management of a turn around project are similar to a normal project.  It requires a new charter, and project plan to evaluate the failings of the first project and define the actions required to correct course.  There are many dimensions to a troubled project, and many things that must be done.  This will not be an article to attempt to discuss all the aspects of how to address a failed or troubled project, but how to address the communications and more specifically – the public relations during the turn around effort.  Through the course of this blog I have written many articles about public relations on projects.  The communications and public relations campaign of a turn around project certainly require the same PR principles that any project does such as:

• Communications message content focused on benefits, helping to keep stakeholders’ focus on the ultimate goal to be achieved at the end of the journey.
• Messages relating not just the information of activities or events, but conveying the value of those events to the business.
• Communicating information promptly, when it is of prime interest and relevance to stakeholders.
• Being aware of the spin or nuance in a message and selecting the appropriate tone of a message that is right for the target audience.

What is different about a troubled project, however, is that unlike a normal project, the project manager does not start with a clean slate and friendly stakeholders.  On a normal project everyone gives you the benefit of the doubt at the beginning.  The project manager can leverage the natural excitement that exists around a new undertaking and create friends of the project.  Once things begin to go awry, all that is lost and stakeholders are now mad.  The recovery PM operates from a position of a PR deficit.  As the public “face” of the project, he/she may no longer have any credibility and this requires extra finesse in the public relations campaign. 

There is no fast or easy way out of the PR deficit position, other than real performance – i.e. actually beginning to make some of the new commitments.  Until that is possible, a certain amount of humility when wearing the “project face” is just part of the role.  What stakeholders tend to want at this point is honest, clear, reliable, complete, straightforward, and prompt information.  As you and your team are performing discovery and identifying priorities, it is important to publicly acknowledge them – even before you may know the solutions.  This helps ease stakeholders’ anxieties that they have been heard and understood.  Your ability to quickly establish the stakeholders’ belief that the information being communicated is reliable and objective establishes credibility. It needs to be complete to insure that quality decisions are derived as a result.   Stakeholders want an open admission of mistakes that were made.  Fortunately, project management gives us a good framework that allows us to discuss such things as lessons learned in a respectful way that retains dignity for the team – especially when combined with process improvements that were implemented as a result of those lessons.  This is important to preserve the morale of the team because the team must carry out the required recovery work. 

A recovery project will probably institute more frequent feedback loops and communications should follow suit.  You cannot afford to let the silence created by a void of information generate panic driven false rumors.  PR during a troubled project therefore becomes very time consuming and it is a good idea to consider appointing a lead who is devoted to managing PR and frequent, prompt communications while the implementation team focuses on resolving issues and carrying out the work.

But what if the stakeholders themselves are the problem?  As described in the ESI International white paper entitled “Saving Troubled Projects”, one of the first things that must be discovered is project history and sensitivities.  As with any project, having a strong supporting sponsor with the appropriate level of seniority and credibility is essential for success.  This sends a clear message to stakeholders that this work is of importance.  The recovery project manager must make an effort to understand the political environment the project has operated in.  He/she must fully understand the objectives of the project, as well as the objectives and motivations of the stakeholders and where those may have been in conflict.  The sponsor should be leveraged to handle stakeholders whose motivations may be at cross purposes with the goals and objectives stated in the charter. 

In summary, a recovery project manager must use all the public relations tools employed on normal projects to an even greater degree on a troubled project to keep stakeholders eyes on the prize as the team rights the ship back on course.

According to Dictionary.com, a template is “anything that determines or serves as a pattern; a model”.  The idea of a Requirements Template is to provide your organization with a thorough and far-reaching list of questions or areas of inquiry to either answer or rule out at the beginning of every project.  If you include input from enough people and groups, whether they typically identified as project stakeholders or not, you can eliminate many of the scope problems that your organization’s projects might have encountered in the past. 

If you ever do projects for external customers, start your template-building exercise with Marketing and Business Development.  Ask them about what types of features customer and prospects initially express interest in and what marketing and advertising messages they respond to.  This can give you some good high-level areas of inquiry for your Template by helping you understand what prompts your external customers to engage with your organization. 

Next, visit with the Sales group and ask them to think about every problem customers have identified as wanting to solve when they accept a sales proposal.  Ask them also to think about customer satisfaction issues after a sale is completed:  what characterized projects that had satisfied customers, and what characterized projects that didn’t.  Ask them to describe situations where the customer was temporarily unhappy and why.  Ask to see any type of documentation they use to begin identifying what a customer wants. Then start building your list of questions. 

If you are dealing only with internal customers, start by reviewing the documents that accompany any request for a new project.  You want to include all of this information, but your template will go into much greater detail.  Interview someone from your organization’s Steering Committee and ask them what is missing from the current initiation documents they use.  Ask for examples of specific projects that got kicked back from the Steering Committee due to insufficient information, and get them to identify the types of additional information needed for them to make a ruling on a new project.  Continue building your Template by adding this to your list of questions.

Next, visit with all the teams that are responsible for executing the project plan.  Talk to developers, DBAs, cost estimators, trainers, folks who do the documentation; basically, everyone who actually performs work on a project in your organization.  Ask them for a list of everything they end up needing to know in the middle of the project that no one ever asked at the beginning.  Ask them what kind of work they are doing in the stabilization period, and if that work is a result of missed requirements.  Ask them for the most common examples, as well as the outliers.  Your goal is to create a comprehensive list of everything that should be considered at the beginning of a project.

Then move on to your support teams – whoever is responsible for the product of the project once it is operational.  Ask them to identify the things they wish someone on the project team was asking about.  Again, ask for the odd and unusual situations as well as the most common examples.

Finally, spend a little time with other groups that may not be at all involved in the project, but can potentially be affected problems with a project, like Legal, Accounting, Corporate Compliance and Public Relations.  Ask if they have ever been affected by missed project requirements, or have an area of potential concern around project requirements.  Document their concerns as areas of inquiry to consider during the requirements phase.

If you have all these conversations and hear all these war stories, you will be able to create a useful tool for the people in your organization who have the responsibility of collecting requirements.  Continue to updated and modify your Requirements Template as new information becomes available. 

In addition to getting your project off to a good start and nipping some scope creep issues in the bud, you may find that this tool helps you have better conversations with customers, both internal and external, by helping them uncover needs they didn’t know they had or gaps in their process they hadn’t discovered yet.

Good luck!

Ultimately, it came down to Holly Robinson Peete and Bret Michaels, neither whom I would have predicted would be a finalist.  Both played the game well, and if you could take the best of both of them, you would have the Super Hero of Project Managers: Bret’s creativity, warmth and ability to leverage the skills of his resources with Holly’s fierce determination and drive for success.  Over the course of 11 weekly episodes, Bret ultimately impressed Donald Trump the most and was offered the ostensible job of Celebrity Apprentice, following in the footsteps of Piers Morgan and Joan Rivers.

The show mimics the real world insofar as most of us have about 12 weeks, or 90 days, during which our new organization can terminate us without cause.  In the United States at least, we have 90 days to impress our new manager, peers and direct reports, make them happy they hired us, and want to keep us around. 

In his book “The First 90 Days: Critical Success Strategies for New Leaders at All Levels”, Michael Watkins identifies 10 key challenge areas that a leader in a new situation needs to manage. 

One of these challenges, which Watkins characterizes as “negotiating success”, involves your manager.  “Because no other single relationship is more important, you need to figure out how to build a productive working relationship with your new boss and manage his or her expectations.”  In the Celebrity Apprentice example, we know that Trump has a history of picking an outlandish figure as his celebrity apprentice, a real character.  He loves a clever turn of phrase, as both Piers Morgan and Joan Rivers did so well.  Although Bret is much kinder then either of his predecessors, his colorful style of dress, peculiar vernacular and endearing view of the world undoubtedly provided enough flair to appeal to Trump, who wanted some celebrity “cred by association”. 

Another key challenge that Watkins recognizes is to secure early wins.  “Early wins build your credibility and create momentum.  They create virtuous cycles that leverage the energy you are putting into the organization to create a pervasive sense that good things are happening.”  This season started with Bret as the winning project manager for the first task.  Joan Rivers was the winning project manager for the first task last season.  Piers Morgan, while not the project manager, served on the winning team for the first task and differentiated himself from the first episode by gleefully engaging in a blood feud with arch-villain Omarosa.   

The ability to create coalitions is a further key challenge identified by Watkins.  “Your success will depend on your ability to influence people outside your direct line of control.  Supportive alliances, both internal and external, will be necessary to achieve your goals”.  Bret did a masterful job in this area, and may have been where he really pulled ahead of Holly’s grim efficiency.  Bret was nice to everyone and never lowered himself to interpersonal squabbles.  Early in the season, like the Kodak challenge in Episode Two, Bret acted a little high maintenance and needed an inordinate amount of hand-holding, but he pulled himself together and ultimately won the respect and admiration of all of his team mates, even before facing any of the health challenges that he and his family were confronted with during the season. 

The Celebrity Apprentice demonstrates that just because we made the first cut doesn’t mean we will have a successful run at an organization, and offers lessons to us all on how to navigate those critical first three months to ensure that we really get a chance to make a long-term impact.

Cyndi Lauper has consistently been a distraction to her team in the first three episodes of Celebrity Apprentice.  Several of her team members on Tenacity, the women’s team, have whined about her in their camera confessionals.  While all of the women claim to “love” her, they all agree that she is a confounding presence, as they labor through each task to the background melody of her stream-of-conscious narratives.

In Episode 3, Tenacity won the challenge, which was to create a multi-page advertorial for Lifelock and Norton 360.  However, Summer Sanders gave a surprisingly weak performance as Project Manager, due in part to her inability to handle Cyndi in an honest and respectful way. 

During Tenacity’s brief meeting with the client, Cyndi dominated the conversation with all kinds of random questions about her 11-year-old son’s use of the internet.  From there, the team moved quickly on to finding a job for Cyndi that would minimize her disruptiveness and allow the rest of the team members to focus, just like they did in the previous two challenges. 

Instead of anyone pulling Cyndi aside and letting her know the effect she was having on the team, no one, the Project Manager included, had enough respect for Cyndi to address the issue straight on, although they were all fully capable of moaning about it when they were alone with the camera.

Things finally came to a head in the Board Room, when The Donald quizzed each team about their performance and their team dynamics before letting them know which team won the challenge.  When asked about her team, Summer prattled on about Cyndi and “her stories”.  Cyndi seemed genuinely surprised by Summer’s complaints and said she did not realize that she had been telling stories.  Summer continued to make an uncomfortable situation worse by nattering on about how she loved Cyndi’s stories, just not always at the time Cyndi chose to tell them. 

Even though the women won, Summer ended up in tears, overwrought as she told the camera how bad she felt about hurting Cyndi’s feelings.  This was followed by Summer having a talk with Cyndi where she apologized and blamed herself for blindsiding Cyndi with her complaints about Cyndi’s stories, missing yet another opportunity to tell Cyndi that her behavior was consistently disruptive to the team. 

My question is, how hurt will Cyndi feel when she watches the show and discovers that everyone was complaining about her and no one had the decency to tell her what was going on? Were any hurt feelings actually spared by Summer’s avoidance of the issue?

In a November 2008 article in Harvard University’s Negotiation Journal, researchers talked about the very behavior that Summer demonstrated, which is called smoothing.  “Smoothing involves giving in to the other party while ignoring one’s own needs. We found an almost 20-percent difference with females vs. males. The data indicates that women are more apt to try to smooth over the situation in order to maintain harmony.”  The article goes on to caution, “One must realize that smoothing is a temporary fix and not a long-term solution”, which is exactly what we saw in this situation.  Summer smoothed over the issue and Cyndi still has no idea of the effect she is having on her team. 

Stay tuned for next week when Cyndi’s behavior will continue to be an issue!  And talk to us about it by joining our conversation on Twitter during the show.  Just search for #celebrityPM.

The basic premise is quite simple: each participant gets to cast multiple votes on a list of options.  If the list is static, one not generated by the group, this can even be done before a brainstorming meeting. 

The Card Sort: if you have a pre-defined list of options and want to have a clear idea of priorities before the meeting starts, use the Card Sort.  Provide each meeting attendee with a list of options and ask them to sort the options in order of their preference.  This can be done literally, by providing each participant with a stack of index cards (one option written on each card) and ask them to rank the cards.  This can also be done virtually, by sending out a spreadsheet and asking participants to identify the options as their first choice, second choice, etc.  On online survey tool will allow participants to submit their rankings anonymously, if that is important to you group.  Regardless of how you get the information, you will benefit by understanding what your group is thinking before your meeting starts.  If you come in to a brainstorming session with your priorities already identified, you can spend your time thinking about those options instead of coming to agreement on what they are. 

The Poker Game: multi-voting in its truest sense allows participants to cast more than one vote on a list of options the group has created.  There are generally two rules: each participant gets the same number of votes, usually 3 or 5, and can only vote for a certain idea so many times.  Casting votes can be as simple as each participant putting a dot or check mark by the options of their choice, or can involve each participant getting certain number of relics (for example, poker chips) to spend on the options they like best. 

Target Exercise: this technique can help your team identify not only what the priorities are, but what options should be put on the backburner.  For each option under consideration, draw a target on a whiteboard or large piece of butcher paper, with each circle marked as follows:

• Center circle – CRITICAL
• 2^nd circle – Somewhat Important
• 3^rd circle – Marginally Important
• Outer circle – Unimportant

Give each participant a large marker, a stack of post-it notes or a sheet of sticky dots.  For every option, each participant puts a dot in the circle that best represents their feelings about that option.  This allows the group to quickly see which options the group is in agreement on (whether they feel the option is important or unimportant) and which options might need more consideration or discussion because they group lacks consensus.

 This concludes my team creativity series.  I hope you have enjoyed reading it as much as I have enjoyed writing it.