Why do organizations constantly rely on their PMs to also perform key technical work on a project? Several reasons. One is reality. We are doing more with less now, and the reality is that we may not have the personnel available to assign different people to those roles. Another reason is that most projects are small enough that working within both roles is not a problem. Still another reason is because often the PM is assigned because they are a strong team member and one of the higher performing employees. Their reward is being given the opportunity of managing a new effort. During that effort, the organization cannot afford to have this superior performer NOT working on what they do best — the  technical work of the project.

The trouble occurs when the project is large or complex. In this case, balancing both the management aspect (PM) and performing key SME work can be overwhelming and tough to balance, often resulting in neither being done well. Few people can be actively involved in their technical focus, or SME activity, when needed and then be able to step back and see the big picture from an unbiased management perspective.

This is true both from a time as well as a viewpoint perspective. Most people allow their SME time to overtake management time until there is a crisis, at which time they go into reactionary or fire-fighting mode to deal with the issue (often later than they should) and survive. From the viewpoint perspective, it is difficult for someone who has been deeply engrossed in one aspect of the project, such as their area of technical expertise, to step back and address issues and concerns from all areas objectively. Mere mortals cannot always do this. Yes, we have all been asked to do this and some have done it fairly well, but the larger and more complex the project, the more difficult and unrealistic the expectation.

Add to this the fact that when PMs are assigned both roles, planning takes a back seat. When this happens, there often isn’t clear understanding or definition of scope, schedule, roles, expectations, constraints, etc., compounding the number and kinds of potential problems experienced later. Without an initial definition of those various aspects of the project, it is harder to get agreement on the possible fix to allow the team to move the project forward.

Projects may be completed in this structure, but at what cost? Are team members burned out? Were there more crises than necessary? What superhuman, or brute force, effort did it take to get the effort done? Was it worth it? These are valuable questions to ask, and even better if asked first when assigning roles.

This month, the articles appearing on Forward Momentum focus on a discussion regarding the use and abuse of best practices in project management. It’s fair to assume that there are a large number of opinions on this matter, as are the number of anecdotal examples that could be given. That said, here are two examples of abuse that immediately come to mind.

Abuse #1 – Best practice does not imply a “paint by numbers” methodology.

Project managers should not consider “best practices” as simply a series of rote activities applicable to every project regardless of subject, size and scope. They are not intended to promote a “paint by numbers” approach where the project manager has little substantive understanding of what is being undertaken and the associated risks. No, some better definitions can be found with a quick search on the Internet. Here are three separate, but similar explanations of the term.

First definition: “Best practices can be defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people. A given best practice is only applicable to particular condition or circumstance and may have to be modified or adapted for similar circumstances. In addition, a “best” practice can evolve to become better as improvements are discovered.”

Second definition: “Methods and techniques that have consistently shown results superior than those achieved with other means, and which are used as benchmarks to strive for. There is, however, no practice that is best for everyone or in every situation, and no best practice remains best for very long as people keep on finding better ways of doing things.”

Third definition: “a practice which is most appropriate under the circumstances, esp. as considered acceptable or regulated in business; a technique or methodology that, through experience and research, has reliably led to a desired or optimum result.”

Notice that the common thread between all three definitions is the need for adaptation. In the realm of project management, one size definitely does not fit all. We occasionally, however, may encounter project managers who confuse the relatively mechanical exercises of schedule monitoring or meeting facilitation with robust project leadership. The Project Management Institute’s Project Management Body of Knowledge (PMBOK) takes almost 400 pages to describe five basic process groups and nine knowledge areas, all designed around the concept of “best practices”. A significant portion of the material discusses techniques for avoiding potential issues related to human interaction and perception. Anyone who’s taken the PMP exam knows that some of the questions can be rather ambiguous and subject to interpretation. There is simply no instruction manual for every situation, which implies that the project manager needs to have a fundamental understanding of the project at hand and may be required to drill down and become a subject matter expert in order to resolve particular issues. Project management is not an administrative role and the PMBOK is definitely not a cookbook. It is a set of best practice tools designed to help the project manager lead participants on a journey that hopefully will create something of value for the organization.

Abuse #2 – Best practice does not confuse the over-arching project leadership with task ownership.

You are the project manager, which means that you have a responsibility to lead and delegate. You are not a resource for taking on tasks that others prefer to bounce back in your direction. Following “best practices” requires clear communication of all responsibilities before the plan is executed. This is important since there may be a tendency for some personality types to define for themselves a very narrow scope of work if they perceive any ambiguity. It can lead to unintended finger pointing, confusion and in some cases, hostility.

Case in point: I was recently in an awkward meeting with a design engineer and the end-user. The engineer was responsible for figuring out the impact to the IT infrastructure in order to implement a new messaging system. It was obvious that he needed to do some more investigative work before a design could be drafted, so I asked him to contact the building engineer. He refused and then issued a rather smug proclamation that communication between team members was “the project manager’s responsibility.” It would have been better if I had aligned my expectations with the engineer before the meeting with the end-user, but I made an assumption that the engineer was capable of engaging others by picking up the phone. Apparently, I was wrong.

Make no mistake. Following best practices means that you should perform due diligence as a project manager in order to facilitate communication to stakeholders, both from within and outside of the project team. But it does not mean you are responsible for brokering interactions between team members. If someone on your project is not receptive to communicating and coordinating within the scope of their task assignments, then it may be wise to have a frank discussion in order to level-set expectations. If they still prefer to define their own boundaries, then it may be appropriate to find another resource. You will have enough to do in providing planning, leadership, tracking, decision-making and status. Don’t take on the work of others late in the game for fear of project failure. Negotiate expectations up front.

As a learning professional, I am no stranger to having the business units that I support approach me with issues that require solutions. In most cases, they come looking for training solutions when the bottom line results aren’t appearing as expected. Their approach reminds me of one of my favorite Saturday Night Live skits.

During the Saturday Night Live Weekend Update, Kenan Thompson portrays a very concerned financial expert whose solution to the recent financial crisis is that someone should “Fix it!” In his humorous tirade, he outlines several steps that “someone” needs to do to fix the problem:

1. Identify the problem
2. Fix it
3. Identify another problem
4. Fix it
5. Repeat as necessary until it’s all fixed!

I’m sure many of you can relate to this.

Typically, the next step is to start problem-solving, asking tough questions about the environment, prior performance, management, obstacles, motivation, prior knowledge and a multitude of factors that likely impact performance. Unfortunately, the business didn’t come to you for questions; they came for answers. They might even feel frustrated because they perceive your line of questioning as an indictment of their own research into the issue!

Learning organizations are under huge pressure to generate ROI for training so they can’t run out training solutions for every issue that arises especially if the problem is unrelated to training. If they don’t respond they may be seen as uncooperative, and so the business unit takes matters into its own hands. Neither is a high quality outcome.

You need to do a thorough analysis of the problem, so look for ways to collaborate with the business owner to find the root causes. Engage them to help you explore the aspects of performance that you know are most relevant but that they may not have thought about.

The challenge is to be perceived as the team that helps the organization reach its goals in the best manner possible. By focusing on the desired behavior, we can usually offer our clients and stakeholders solutions that meet the need and get results by giving them the choice of options and showing them the ROI.

1. Always provide a good / better / best menu of choices with price points. Even the staunchest client has the good of the organization in mind. Faced with having to diminish results based on training cost, they will often choose the solution that makes the most sense.
2. Stay focused on the desired behavior. Clients love to talk about all the things they believe learners should know to do the job. Unfortunately, all that extra knowledge might be getting in the way. Document the desired behavior, run the task analysis and return with sound data to make your case for the simplest solution.
3. Get outside your own comfort zone. The best solution might be a simple communication piece or policy update that the learning organization is typically not responsible for creating. Look at that as an opportunity to collaborate across the organization and influence others to think about performance. This might also be a great opportunity to leverage some informal learning strategies like wikis or peer coaching rather than developing a full-blown training intervention.

Sometimes in order to “fix it,” training is not required. If based on your analysis you think there are better ways to solve the problem, offer up those solutions not as a trainer but as a performance consultant. Utilize what you know of visual media and learning to make communication tools and job aids easier to read and absorb. Make recommendations to the business regarding process or task changes. The simplicity of the solution may earn you more influence and credibility in the end and make an even bigger impact to the bottom line.

Project Managers are notorious for it. On top of business jargon we add our own unique language and terms. Writers on Star Trek call it technobabble, we can call ours PM-speak. We have our own language and acronyms, just as every organization has their favorite sayings and acronyms. Wouldn’t it be nice if we were all issued a universal translator or babble fish when we walk into an organization? But we aren’t, and we have to figure it out as we go along. We have to make an effort to be clear when we speak to others while also making sure that we understand those using lingo on us.

Why are they using that lingo? Does everyone understand the message the same way? Often, the answer is no, even when we are trying. But everyone does not always try, which makes it worse.

I am sure we can all think of a person who is notorious difficult to understand. Some people do this to demonstrate membership in a special club, like some inside joke or story. Some people do it to purposely remain vague and keep people guessing. They like the control and/or think it gives them flexibility. Some do it to show their knowledge without realizing that others aren’t impressed because they are too occupied in their minds trying to figure out what is being said. Others are vague and speak in jargon without realizing they are doing it and without realizing the impact of their strange language. Speaking in terms that not everyone understands clearly allows for different interpretations at best and confusion, frustration and rework at worst. This often leads to decreased morale and late deliverables.

How can we avoid falling into this trap? Here are some tricks I have used:

1. Cliches and acronyms: I have found that when teaching classes, I make more of an effort when I know I have an audience new to the topic or when the audience is made up of non-native English speakers. This helps me catch clichés and acronyms. I didn’t realize how often I used clichés until making this effort. At first, I would struggle to make my point without using a favored cliché. With practice, it gets better.
2. Local terminology: Make an effort to watch local or geographic terminology as well as proper names. To catch other technical or project management-specific terms, watch for glimpses of confusion or too-quick agreement from the other party. Also, think back to when you were just out of school and beginning your first professional job. How did it feel to listen to those around you discuss things that you did not fully understand? Make yourself aware of industry-specific or company-specific terms that you may be using. You have probably been using them for so long you don’t even think about it anymore. If your audience consists of people outside your organization or new to your organization, they will not be familiar with your organization’s culture, pet phrases, stories, history, and possibly organization chart. They may not know very simple things like division or document names. Something as simple as that can confuse people. When a term or name is thrown out that the other person is not familiar with, they will switch their focus from listening to you to internally trying to figure out what you meant. They will then fall further behind in comprehending the conversation, creating a spiral that may be difficult to break without some (or much) back-tracking.
3. Organize and rehearse: Carefully think through your message and how you will convey it before you speak. Mentally rehearse key or tricky discussion points ahead of time where necessary. It will make a difference.
4. Watch the body language: Most of the message received during communications is non-verbal, which includes your body language. When you are speaking to someone in person or using video conferencing, remember that body language will override your words if the two are not aligned. Don’t let the rolling of your eyes or sarcastic tone discourage the other party from speaking up if communications are not clear. Try to be empathetic and remain open-minded.

What techniques have you used to avoid misunderstandings? If we all share a tip, together we can get better.

I think you would whole-heartedly agree that Matrix Management is a well-established, well-recognized foundation of project management methodology.   Therefore, it must be in keeping with all the other basic truths of PM and just plain old good management– or is it? 

If one of our goals is to KISS (Keep it Simple, Stupid!), does Matrix Management align with that goal?  It SOUNDS simple: all the people with similar skills regardless of their direct line of supervision are pooled and supervised by a person responsible to the project.  Simple. 

So what gets complicated?  What about conflicting loyalties and priorities?  Those of us with both project and operations duties often hear that “Production is King” or “Operations is Priority Number One”.  But when a project deadline is looming, whose work takes precedence?  Two managers must now negotiate to answer that question.

Where are Matrix Management resources located, and how much independence and autonomy do they have?  As often encountered in truly virtual teams, not seeing someone face-to-face on a regular basis can have its complications.  Diligent oversight by both the direct supervisor and the project manager is imperative to execute and track work effectively.

So, what’s a KISS advocate to do?  First, take full advantage of the opportunity to foster the specialization that comes with matrix management and offer your staff the corresponding professional development it can provide.  Second, encourage the communication channels that are created as all the subject matter experts in one area are under your supervision.

And, Keep it Simple!

Recently, we have seen some good and bad examples in the news regarding reacting to making mistakes. Professionally, what can we learn from these?

First, let’s discuss different reactions to mistakes. There are three approaches to handle a mistake: apologize right away, apologize to save face and don’t apologize at all.

There was the recent baseball game involving the Detroit Tigers’ pitcher Armando Galarraga. Up until the end of the game, he had pitched the elusive perfect game, retiring 26 straight batters. It appeared that batter #27 was easily out but the umpire called the runner safe, causing the game not to go down in the record books as a perfect game. Later that evening, when umpire Jim Joyce saw replays, he realized he made a bad call which cost Armando Galarraga a perfect game.

Joyce had the presence of mind to know and admit when he made a mistake. The next day, Joyce admitted his mistake and expressed real remorse in his apology to Galarraga, saying that he hasn’t forgiven himself. To his credit, Galarraga graciously accepted the apology, recognizing that there are times when mistakes are made.

A second example of a recent mistake we have heard plenty about in the news is the BP oil spill. Here, as with Toyota earlier this year, BP refused to admit wrongdoing on their part, finding many other items and people to blame. Finally, when BP’s CEO Tony Hayward did issue an apology in a TV commercial, it was largely seen as insincere, inauthentic. They appeared more sorry to have gotten caught than for the tragedy caused.

A third approach is to ignore the mistake entirely as demonstrated by FIFA and Malian referee Koman Coulibaly. After countless hours of watching video tape no one seems to be able to explain the mysterious foul that caused the final goal scored by the U.S. to be disallowed. This led to a draw between Slovenia and the U.S. and could have ramifications later in the tournament. So far, even though the game report claims a foul on Edu of the U.S. team, FIFA has not responded to the criticisms levied by the international media.

Why do I mention these situations? Because as leaders, managers or employees in the business world, we can learn from the actions of others. Is your project going to be late? Are you starting to run over budget? Did an unexpected event occur that you don’t have a plan for? Don’t be afraid to admit mistakes if they are real. If there is a real mistake made, admit it and discuss what is being done to fix it. This doesn’t mean you go around admitting every little thing. Focus on the ones that matter, those with repercussions. Not admitting a mistake or trying to shift the blame to someone or something else doesn’t fool anyone, except maybe yourself. And in the process, you will lose credibility. We would do well to remember this when working with our customers, bosses or team members.

Patrick Lencioni does a good job of describing this in his new book Getting Naked. He discusses how being open, transparent, even vulnerable with clients allows for trust and honest, true relationships to build. His consulting firm has operated on that premise for years and has grown.

There are even consultants now who advise firms on how to make amends, understanding that admitting a mistake could include accepting a possible legal liability. According to the June 13, 2010 Dallas Morning News, Lee Taft of Taft Solutions says that a true apology can have a positive legal effect. For example, in 2004, the Dallas Police Department was involved in a fake drug scandal. Rather than pretend nothing happened or try to blame someone else, the Dallas City Council apologized to victims and announced that new measures would be put in place to make sure this could not happen again. There was a legal risk in admitting this so openly and there were legal awards paid out because of this scandal, but the conclusion by some is that the city paid less than they might have because they removed the “outrage factor” and inflated awards.

Just as there are risks when admitting mistakes, there are risks in not admitting a mistake. A study in the New England Journal of Medicine shows that doctors who make mistakes and stay silent increase their suffering, putting them at higher risk for addiction, burnout or suicide.

What can we learn from all this? Remember that you are not fooling anyone by pretending an error or bad situation didn’t happen. The important thing is that you step up and do your best to fix it. Keep honest and open lines of communication. That can overcome many legitimate mistakes. In summary:

1. Apologize quickly and with feeling, showing that you understand the impact of your actions
2. Offer a solution or remedy if one is available
3. Show how you plan to work this into your process to prevent it from happening again

You’ve probably heard the acronym “KISS”, which stands for “keep it simple, stupid”.  I must admit, I was never a fan of any phrase that assumes the audience has diminished capacity.  And in this case, there is definitely nothing “stupid” about the benefits of keeping things simple, particularly when it applies to project management.

If you have spent any time studying project management courses or preparing for the Project Management Institute’s PMP exam, then you know that there is a good deal of complexity and abstract thought associated with generally accepted project management principles.  The number of concepts can be overwhelming.  They include a good understanding of organizational structures, project scope, time management, cost containment, quality metrics, human resource management, communication plans, risk mitigation and even procurement.  The number of tools and techniques associated with project initiation, control, monitoring and closure can number into the hundreds.  Some might even argue they number into the thousands.  Yet, as with all things, we soon learn to prioritize and select the tools and techniques which suit our project management style as well as the scope and duration of the efforts we undertake.

A case could be made that you could count on your fingers the essential components of a good project management plan.  In my world, these would include: 

1. A statement of business requirements to be addressed.
2. Project charters, which include information identifying project sponsors, the project manager, a project ID and the anticipated duration of the effort.
3. A definitive statement of project goals and criteria for measuring project success.
4. Specific definitions regarding what is within scope and beyond the scope of the project.
5. Risk assessments, including an appropriate level of contingency planning. 
6. A stakeholder list with subsets identifying active project participants, roles, specific responsibilities and contact information.
7. A definitive list of project deliverables.
8. The project budget.
9. The communication plan and meeting schedule.
10. Executive level status reports designed to summarize past expenditures, provide fiscal projections and identify issues requiring escalation.
11. Meeting minutes, action items and issues logs, which I consolidate into something called “project notes”.
12. Detailed project tasks, assignments and associated schedules.

Okay, I admit I don’t have 12 fingers, but I’m sure you get the idea.  Having small set of project definitions, controls and reporting mechanisms is one way to keep things relatively simple so that everyone has the opportunity to maintain the big picture during the life of the project.  Methodologies, forms and formal procedures can be beneficial until they reach a point of critical mass.  When that happens, they may actually impede progress, hinder communication and obfuscate status.  The confusion and associated slow response to the tragic oil spill in the Gulf comes to mind.  Please forgive my armchair quarterback analysis, but the situation might have been significantly better if some very basic questions had been answered before attempting to address the myriad of details.  Specifically, 

• Who’s in charge? 
• What are the immediate and long term objectives?
• What is the anticipated duration?
• How much money is available?
• Who is available to help?
• What is the communication plan?
• What contingencies will be executed on a specific date if “Plan A” is unsuccessful?

If you can get your head around those questions without referring to reams of documentation, then you have a much better chance for project success.

Less is sometimes more.

I have always prided myself on my ability to manage and motivate my team as well as to get many of my employees promoted. I took the time to get to know their business and personal goals, to clear roadblocks, and to coach and develop them. However, it is a little different story when your team is completely virtual.

When I moved to the role of managing virtual team members, some aspects of my old management approach still worked well while others fell woefully short. Even the aspects that worked, though, had to be modified. For example, I couldn’t walk around and casually talk to everyone to see what they were working on, where they were concerned, and understand the daily nuances of the work at hand. This made a difference when communicating with my new virtual team. I found that much as I tried, I couldn’t relate to everyone as well as I used to. I started to be taken by surprise by things that happened (or more often, what didn’t happen), to hear of obstacles that I didn’t know were presenting themselves, etc.

What did I learn from this?

1)      Extra touch. My general management style was still good, but needed to be modified to include good use of technology and more conscious effort to keep in touch with everyone. It takes extra time to talk to people and get to know them. It also means making an effort to schedule a few more and focused meetings. When working remotely, the team default is to stay separate and not schedule any meetings. Also, it is not enough for me to talk to each person individually; I also have to make sure they are talking to each other. Surprisingly, often they aren’t.

2)      Increase feedback provided. In an office it was easy for me to provide ongoing, informal feedback to individuals to let them know how they were doing and to help develop them. Remotely, that is more difficult. I have to make an effort to let people know what has been done well or what was not done as I expected and encourage interaction with that person. I have to create a feeling of trust and openness so the dialogue can occur even when I do not initiate the conversation.

3)      Additional planning. I have to perform additional planning when communicating work to be done. This may include putting instructions in writing or creating more checklists than before. It may also mean creating processes for task management and completion, problem solving or conflict management.  Sometimes, processes need to be created for things taken for granted in a co-located office. Processes for version control, hand-offs, checklists of the common errors in completing work may have to be created to produce a consistent, quality product among scattered team members. 

4)      Use technology, but don’t let team members hide behind it. I had to adapt to relying a little more on lack of touch, such as using email, but not too much, because so much of the message is lost with this method of communicating. In today’s society, the bigger problem is getting people away from email and IM and getting them to actually call and talk to another team member. Yes, more communications are conducted using email and IM, and much of it is fine and has served us well. However, more misunderstandings do arise when using this medium and I have to be ready to step in when necessary to coordinate a call or a meeting to ensure people actually talk to each other to work things out. Other tools such as shared sites or collaborative software are essential.

5)      Meet in person. Make an effort to bring people together in person where possible. Have you ever noticed that you can build a pretty good working relationship with someone over the phone or over email, but once you meet, that relationship has moved to a whole new level? It’s different. That’s the power of face-to-face. Try to get everyone to meet each other at least once. Then the interactions are a little more personal and (hopefully) even better.

Working with virtual teams and PMOs has enough challenges when they are all contained in the USA; however when these teams are global with different time zones and languages, it has a certain dimension that adds “interest” to life!

My first experience with a virtual team was when I based in the UK and was asked to manage a Pan-European project to implement a support service for Hewlett Packard throughout Europe. The application was developed in the US and was being implemented throughout eight European Countries as well as Asia-Pacific and the Americas.

OK so you get the idea – it was certainly a large virtual project. The things that made it interesting to manage were the different cultures, time zones, and languages. Take for example the European cultures – they ranged from those who conducted projects with total precision and accuracy, to those who agreed a course of action then went off and did “their own thing”, to those that tried hard, were great fun to work with, but didn’t always take life too seriously.

In Europe there are only two time zones – UK and European, so this was not a great problem, but we also had regular communications with HQ in Palo Alto on the West Coast – an 8 hour time shift. As for the language issue, I did not adopt the general English approach to languages, “Shout louder in English and they will understand”. I made an attempt to at least show willingness by using my schoolboy French and German which often caused much merriment from my colleagues, leading to everyone resorting to English as the common language – thank goodness.

What were the important lessons I learnt from this experience?

The first one was that for a virtual team, in my opinion it is imperative that the team meets face to face at least once, preferably on a regular basis. I held a kick-off meeting in the UK, then in addition to regular phone conferences we had status meetings every month rotating around the other Countries. When I say “we” I mean just the Project Manager from each Country, not all of the team members. This did of course add to the expense, but in my view the cost was easily justified by the smoother communication and running of the project. There was quite a lot of interdependence between the various Country teams, and trying to negotiate and get another Country to cooperate was so much easier when you had met the person concerned, had a meal and a drink together, and knew something about their family, hobbies, etc.

This leads to communication on a virtual team. This is even more important than with a local team where you can just go and visit a colleague to ask a question and catch up on progress. Communication has to be well thought out and planned taking into account time differences, language issues, project complexities, and cultural differences.

As for the different cultures, I just had to embrace that – I wasn’t going to change their culture, I just had to incorporate it into the plan. Some Countries needed more management or direction, others – once we had agreed a course of action, just went away and did it.

Languages did cause me a problem initially, but it seemed I was the only one who had a problem  – everyone seemed to speak English at least as well as I did, some were even better! There was one Swiss guy who could carry on multiple conversations at dinner in multiple languages, at the same time – I was impressed! In this project I was lucky we all spoke English – had I been dealing with non-European language speakers who could not speak English, it would have been very difficult if not impossible to manage.

I did meet and liaise with the US central developers and the PMs from Asia Pacific and the Americas to discuss any issues and cry on each other shoulders as necessary.

So the key lessons from this and subsequent large virtual teams were to:

1. Meet face to face at least once not just to discuss work but also to socialize and get to know the other team members a little, even though it added cost
2. Allow for and even embrace the different cultures
3. Consider and plan communications very carefully
4. Hope everyone speaks English!! Seriously, this could be a major issue on a global project and it can’t be ignored – a solution to communication and language must be found

We don’t find the concept of trust on most traditional lists of project critical success factors. Yet it may be the number one consideration in establishing and maintaining a high-performing virtual team. While it can be argued that trusting relationships are needed by all teams, they are even more important to virtual teams because of a lack of face-to-face time.

Let’s face it – we wonder what those people are REALLY doing? We email them; maybe call them, but have we ever met face-to-face? Do we share anything of ourselves beyond work issues?  Do we actually see them operate on a daily basis? Are THEY working as hard as WE are?

While multiple media are the channels by which members make the “physical” connection, there is little to no face-face communication in a virtual team. Yet it is only through meaningful interactions that people develop trusting relationships. More importantly, informal encounters (walking through the hallway, meeting in the kitchen), something that virtual team members cannot do even with the most advanced technology, have been shown to provide a common perspective that leads to enhanced collaborations.  

This is yet another challenge for the Virtual Team Project Manager to address. Building and then maintaining trust, which can easily be fractured given time and spatial differences, requires genuinely engaging the team toward that end. If trust can be achieved, more open communication, cooperation, a higher quality of decision-making, and more satisfaction in the decision-making process follows.