Social media tools appeal to that part of all of us that want and need to connect to other humans like us, – to find groups, clubs, lodges, and communities that we have something in common with and contribute in a meaningful way – even if it’s to just share a story or an insight that is uniquely us.  We all crave a sense of belonging, contribution, enrichment, and fellowship.  That’s why we join churches, gyms, civic and professional organizations, sororities, fraternities, etc.  When we are comfortably established within a circle, we naturally want to reach out and keep up and find out what’s new within our circle and share the thoughts, ideas and events that are important to us.  Social media platforms allow us the ability to do this easily and virtually.  Since we have the same needs on projects – to establish an environment that fosters effective communication and information flow between stakeholders, it would seem that social media tools would be a natural answer.  Why then, is there not more success?

A Brand Science Institute study performed in Europe in August 2010 suggested that most social media projects will fail.  As commented further by Jacob Morgan of Chess Media Group, a management consultancy and strategic advisory firm on social business, this is because clearly defined values are usually not established at the onset of a social strategy for both the customer and the company.  Creating a Facebook page or a Twitter account because it’s “cool” , but not really knowing what you plan to do with it is a recipe for failure.  The project will end up with a presence that has unorganized, uncontrolled, or nonexistent content.   Here are some specific tips for using social media tools on projects:

• First, establish a strategy and purpose for the social media tools chosen.  This could be something such as to promote collaboration and foster active participation in communications – both the sending and receiving of information.
• Establish policies and procedures.  Determine any security barriers:  will external internet platforms be acceptable for use and if so how?    If not, create tools or “characteristics” internally using sharepoint or the intranet.  Define ground rules for usage – what restrictions will be enforced.  How will the tools be moderated, and who will do the moderation?  Document the calendar of publications, or any expectations of how the tools should be used.  Create any templates or forms that will be employed.
• Suggestions for project specific uses of social media tools:
  • Wiki’s – Wiki’s encourage collaboration by team members on project documentation and can be used for any type of project documentation: code, requirements, test cases, design specifications, project management artifacts, or end user help documentation.
  • Blogs – Blogs can be used to allow team members to write articles on progress, challenges, or best practices in their discipline.  Blogs from the project manager could contain the status reports.  Specialty blogs could contain messages from the sponsor.
  • Audio/Video messages – Podcasts (audio messages) and videos can be used for training communications or inspirational messages from the sponsor.  The elements of sound and video add richness to a message and give it more depth and dimension than written text alone.
  • Youtube – Youtube can be used as a repository to research expert presentations on best practices.
  • LinkedIn – Linkedin is a professional virtual networking site, which similar to the use of Youtube can facilitate research.  It supports targeting professionals or organizations by certain search criteria, participating in group discussion threads, posting questions, and recruiting.
  • Twitter – Twitter can be used to post brief updates on project activities available to followers of the account.  Consider the benefits of this as contrasted with more traditional approaches such as emailing a large distribution list or embedding within a long status report.  The account’s historical tweet stream has search capability, hash tags to categorize topics with keywords, and the ability to embed shortened URL’s to point to other web content.  Yammer is a corporate (non public) tool that allows similar functionality if security restrictions do not permit the use of Twitter over the public internet.
  • Facebook – A Facebook page can be set up for the project to post stories about social gatherings of team activities in different locations.  This helps promote bonding between the team members who are not co-located. 

The point is, in order to tap into that natural instinct we all have to reach out to each other and share – which seems to be all too elusive on projects sometimes – we need to incorporate the “F” word.  We need to introduce a little FUN.  The extent to which social media tools are pounded on by our team members outside of work is testament to their appeal, so why not have them work in favor of the project instead of against it?

Project management is always a matter of scale.  It is not a one size fits all proposition and there are times when we as project managers should remember to just do the simple things.  Sometimes the K.I.S.S. (keep it simple stupid) principle is really the best.  Imagine you have just been asked to organize the team rollout victory party for next week.  That’s the project.  You have 2 administrative assistants to help you.  That’s your team.  Are you going to develop a WBS dictionary, document a communication plan, and perform a quantitative assessment of risks?  I doubt it.  By the same token will you abandon any semblance of planning and completely wing it?  I hope not!  Not if you are a project management professional.  Any endeavor that is temporary and produces a unique product, service or result deserves a plan – one of appropriate size and scale.

Scope:  So, in our example you sit down with your 2 administrative assistants in your office and pull up a spreadsheet.  The 3 of you brainstorm what tasks need to be done in the next week to pull off the team party.  You discuss where the party will be held, what food will be brought in, how invitations will be handled, entertainment, etc.  You capture all these tasks in a column of the spreadsheet.  You have just defined the scope of your project as a list of tasks.

Resources: Next, you decide who is going to do each task on your list.  There are only the 3 of you on your team so one of the 3 of you has to be assigned to each task.  In a 2^nd column of the spreadsheet you assign a name to each task.  You have just performed resource allocation.

Schedule: Next, the team needs to determine when each task needs to be done.  This is an example of a time-boxed, fixed date project.  The party will be communicated for a specific date, so all preparation activities must take place prior to that date.  Working backwards from the party date, in a third column, the team fills in target date/times of when tasks must be completed by.  You have just performed activity dependency and scheduling for your project.

Budget: You think about how much each task will likely cost and note that in a 4^th column.  The sum of these cost estimates forms your budget.

Risk:  You ask your team “Is there anything that worries you?”   One of the admin assistants replies: “What if we can’t reserve a restaurant large enough on such short notice?”  So, you decide to add a task to the list to reserve a large conference room at your company and investigate catering at the company as a backup precaution.  You have just performed some risk management planning. Maybe it is not extensive or as rigorous as it could be, but it is better than doing nothing, and probably appropriate for this size effort.

Communication and project execution:  You decide to have a daily 15 minute meeting over the next week as you each carry out your assigned tasks.  I like the agile iterative process format for daily meetings as far as providing a simple way to get project updates.  In each meeting, every team member answers 3 questions:

1. What have you done since the last time we met?
2. What do you plan to do between now and the next time we meet?
3. What impediments are preventing you from making progress?

In answering those 3 questions, you are providing progress measurements that can be compared to the plan.  You are providing forecasts that indicate if adjustments are warranted.  You are highlighting issues and risks that may lead to offline discussions to develop ad hoc workaround plans.

With a simple spreadsheet and some basic, obvious conversation you can manage a small non-complex project.  The tools used are not important, as long as the necessary steps of the project management process are covered.

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.

Defining Thresholds: First off, defining thorough risk response strategies takes time and effort and you want to apply this effort where it makes the most sense.  Assuming that during the qualitative and quantitative assessment steps, some risks will be deemed low priority or less costly, you will probably not want to devise a strategy for each identified risk in your register.  Therefore, before ever beginning risk identification it’s a good idea to make decisions about which risks will be the ones that will get response plans.  This is usually one of the decisions that are documented in the risk management plan.  This might be a threshold for risk scores (probability X impact) above which the risk will move on to response planning phase.  Or, it might just be that the top X % of risks in priority order will be addressed.

Risk Response Types: Risks are uncertain events and can be either negative or positive – i.e. threats or opportunities. Both risk types have a response option of simply accepting the risk and doing nothing proactive to control outcomes.  Beyond that, the response strategy depends on which type of risk you are dealing with.

Threat Responses: 

Avoidance: This is attempting to prevent the threat by developing a strategy to eliminate the cause of the threat.  This assumes you have done a good job during risk identification of analyzing risk event, cause, and effect.

Contingency Plan: If you can’t avoid the threat, the next best response is to develop strategies to brace yourself if it does.  This involves planning for ways to reduce the likelihood of the threat event itself, or reduce the impact.

Fallback Plan: If you implement your contingency plan and it is insufficient, the fallback plan is a secondary response that takes over where the contingency plan failed. 

Transfer:   The transfer option is where we are able to hand over responsibility for dealing with the threat to another party – either through buying insurance, or contracting with a third party.

Triggers/Owners: For all the plans above, triggers and owners should be identified.  Triggers are the activities that signal it is time to activate the plan.  The owner is the person responsible for watching for the trigger and implementing the plan.

Opportunity Responses:

Exploit: This is trying to force the opportunity to come to fruition by increasing the probability of the cause of the opportunity.  This would be the inverse of avoidance for threats, and again would require that you have a good understanding of opportunity event vs. cause.

Enhance: Separate from trying to increase the odds of the cause of the opportunity, this strategy involves trying to increase the likelihood of the opportunity event itself (different from the cause), or increasing the impact of the opportunity once it occurs.  In other words – leveraging a good thing for all it’s worth.

Sharing: The inverse of transfer for a threat, this strategy involves working with another party to help make the opportunity happen – such as perhaps hiring a contractor to perform work.

Watchlist for low priority Risks:   Those risks that don’t make the cut for response planning should still be monitored on a watch list periodically to ensure that their characteristics don’t change and that they don’t require more detailed attention later in the project.

Continued Review through Project execution:   Once response plans are devised, risk teams should review top risks and plans in regular meetings to determine if plans are still appropriate, discuss status of any plans that have been activated, and identify and assess any new risks that may have materialized as the project progresses.  This keeps the project team one step ahead of the problems that are out there waiting to bite you in the rear.  They become less scary.  There are plans in place, triggers identified and owners assigned waiting to take action.  Unanticipated things can still happen, but you have that much more control of the unknown, uncontrollable project landscape.

Qualitative Analysis: During risk identification, the focus was on quantity – identifying as many as possible.  But not all the risks identified merit action.  The purpose of qualitative assessment is to subjectively declare which ones are the most important ones deserving focused attention.  The term subjective is an important distinction from methods used later during quantitative analysis because the assessment is not measured in any precise way.  During qualitative analysis judgment is used to assess evaluations.  This is done by working through the following steps:

1. For each risk, the impact is assessed according to a standard project scale (declared during project risk planning)
2. For each risk the probability or likelihood of occurrence is assessed between (0.0 and .99)
3. The impact rating is multiplied by the probability to obtain a risk score
4. The risk scores are rank ordered to determine the relative priorities
5. According to predetermined thresholds determined during project risk planning, the risks with scores above those thresholds or the top so many in rank order move on to either quantitative analysis (if done for the project) or risk response planning.

Quantitative Analysis:  Not all projects will warrant quantitative analysis.  This is usually only performed for complex projects, long projects, important or high profile projects.  You should use your best judgment as to whether this is warranted or whether it makes more sense to move directly to risk response planning.   Many organizations that perform this process invest in software tools that perform Monte Carlo simulation when there are continuous probability distribution iterations necessary to calculate the possible impact on project objectives.  However, even without such software, it is still possible to perform quantitative analysis by simply shifting emphasis to numerically and objectively analyzing impact and probability for those risks that advance to this phase, rather than the subjective measurement done in qualitative assessment.  Impacts are declared in precise terms of time and cost such as $10000.00 or 10 days rather than a scale value of .8 for example.  Rather than calculating risk scores, expected monetary value (EMV) is used to calculate the exact cost in both time and money for each risk.  This leads to a contingency reserve, which is a budget set aside for funding risk contingency and fallback plans.  The following are the steps:

1. For each risk, the impact in exact time units is assessed (i.e. days, etc.)
2. For each risk, the impact in cost is assessed (i.e. $)
3. If not already available, for each risk numeric probability (0.0 – .99) declared
4. EMV (Time) = probability X Impact time
5. EMV (Cost) = probability X Impact Cost
6. Contingency Reserve (Time) = SUM ( #4)
7. Contingency Reserve (Cost) = SUM (#5)

This allows a more precise calculation of exactly how much the risks and their management will cost.  In my next article I will discuss risk response planning where we will take a look at how to plan strategies to control risks in order to prevent threats and leverage opportunities.

The discipline of risk has six sub component processes:
• Risk management planning
• Risk identification
• Qualitative assessment
• Quantitative assessment
• Risk response planning
• Risk monitoring and controlling
In this article we talk about the first two – planning and identification. In the remaining articles of the series we will discuss the other processes.

Risk Management Planning:  A risk management plan is a document that declares how the remaining steps of the risk process will be performed. It can be a very simple document prepared for each project from an organizational template that states methods and standards that will be utilized for the project. Important things to include in the risk management plan are:
• Methods/techniques to be used for risk identification. Methods/techniques/tools to be used for quantitative analysis (if this step is done)
• Whether quantitative analysis will even be done for the project.
• Historical records and risk categories to use for risk identification – which project archives to explore.
• Roles and responsibilities – who will be part of the team assigned to identify and manage risks.
• Timing – when risk activities will occur – what meetings, etc.
• Definitions of probability and impact – define a common scale and meaning for qualitative ratings.
• Thresholds and tolerances – define the thresholds for advancement of a risk score to risk response planning and where there are special sensitivities (such as cost or time).
• Reporting formats – risk management reports that will be issued and the format.
• Tracking – how the risk process will be reviewed and audited and how activities will be documented. (e.g. where the risk register lives, etc.)
Risk Identification:  After you’ve put some thought into how you are going to do all your risk activities for the entire project, decided who needs to be involved, and written it down into the risk management plan, it’s time to begin identifying risks and writing them down into a risk register. The first thing to be aware of is that a risk is an uncertain event. A fact is NOT a risk. If you know that a certain key team member will not be available for a critical task, that is not a risk to be dealt with in risk management activities. That is a fact to be dealt with in project scope/time/cost/resource activities. So be sure you understand the difference when you begin identifying risks. Also, although not intuitive from the name, a risk can be either positive or negative – either an opportunity or a threat, so be sure to focus on identifying both. Don’t just focus on preventing threats, but also think about how to take advantage of opportunities like sourcing from a supplier that has a lower cost, or finishing a task sooner than planned, etc. Think about who needs to be included to help you with the risk identification activities. These should be subject matter experts who have expertise in the various disciplines involved. This might require that you even go outside the project team and even include customers and stakeholders up and down the organization and in a wide variety of functions. The goal is for quantity over quality at this point so you don’t want to be too restrictive. If someone says “We might get struck by lightning”, go ahead and capture it. You can assess the probability and prioritize it in the next step of the process. Capture all risks in the risk register. Some techniques for risk identification include:
• Review list if risk categories – either a generic commercially available category list or one tailored for your organization. Better still would be one created from past projects. This should not be done as the first risk id step. This should be done after one or two other steps as a “catch-all” to see if anything was missed. The danger in using this first is that people get a false sense of comfort that the list is a comprehensive list of everything possible and they forget to think about what is not on the list.
• Review historical records from previous projects (if available) that are similar to current project – look at risks that were relevant for those projects that may plague your project.
• Review project documentation – There is a reason risk identification comes after all the other project planning activities. You need the output of those exercises to see what the project entails so you know where there is risk. Review the charter, scope statement, WBS, schedule, budget, requirements, specs, etc. for risk.
• Expert Interviews – talk to key stakeholders, customers, sponsors, or members of senior management as necessary to obtain opinions about risk.
• Brainstorming – perhaps the most popular technique, if done properly this method can generate a lot of risks. Best practice is to have 2 scribes in addition to the facilitator. Try to solicit risks in multiple ways: by the project as a whole, by each activity, and by category. Don’t judge – just collect as many as possible! Group them, then clarify.
In the next article we will discuss how to assess and prioritize the risks once you’ve identified them with the qualitative and quantitative assessment steps.

1. March 23 – Passage of the Healthcare Bill, the Patient Protection and Affordable Care Act.  Regardless of what your opinion is on this legislation, the project of getting it passed was successful, and achieved what Presidents as far back as Teddy Roosevelt were not able to accomplish. 
2. April 3 – Arrival of the iPad, demonstrating the beauty of a solution filling a need.  Three million devices have been sold this year and countless new apps have been launched to thrill iPad users. 
3. April 14 – Iceland’s Eyjafjallajokull Volcano shuts down European air travel, and disrupts the global economy.  Although businesses around the world were affected, I can’t imagine that even the best risk managers spent much time and effort mitigating this risk. 
4. April 20 – The BP Oil Spill was an unprecedented disaster, no matter how you look at it.  The final history has yet to be written on this, but I think time will show hideous project management practices before the explosion of the Deepwater Horizon drilling rig, while some pretty rigorous project management practices were applied to the aftermath. 
5. November 2 – Lisa Murkowski becomes the first write-in candidate to win a Senate seat since 1954.  Great lesson in perseverance and the power of getting creative to overcome obstacles. 
6. November 8 – Queen Elizabeth joined Facebook.  In Malcolm Gladwell parlance, this is truly the tipping point for a social media platform, and ought to be considered for every project communication plan. 
7. November 8 – Another lesson in risk planning, or lack thereof, comes from Carnival Cruise Lines.  The Carnival Splendor, with 4,500 souls aboard, lost all power due to a fire in the engine room.  The ship drifted 200 miles off the coast of San Diego, electricity, refrigeration, hot water or air-conditioning, for three days, with aid provided by the US Coast Guard, the US Navy, and Mexican Navy, until a Coast Guard cutter pushed them into the harbor in Ensenada, Mexico.     
8. November 28 – the preview of the so-far disastrous run of Spiderman: Turn off the Dark on Broadway takes place on Thanksgiving weekend.  Rumored to be the most expensive Broadway production in history, with music and lyrics by Bono and The Edge (of U2) and directed by Broadway whiz kid Julie Taymor, the show’s premier has been delayed numerous times due to accidents that led to multiple cast members being injured, as well as the resulting investigations by the New York State Department of Labor and the Actors’ Equity Association.  Opening night is currently scheduled for 7 February.  A project manager’s nightmare… 

• 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.

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 10 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 drug back into non-project work that they 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 who’s 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. 

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.

─ 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.