Miscommunication

The communications mistakes project managers can be divided into 2 categories. Mistakes made with the team, and mistakes made with the customer, client, or sponsors.

The Team

We all like to believe we are proficient communicators, perhaps because we like the sound of our own voices and think no-one could speak more clearly, or write more clearly than we do. We deliver our speech, send our e-mail, distribute our process and then believe the job is done. A critical part of good communication is testing to see if the person or people we’re attempting to communicate with have received and understood our message; failure to check the receipt of the message is one of the most common communications errors. Communication with your team is critical to project success because it’s how you direct project work. In the world of software development project management the mistake is often failing to get commitment from a team member to deliver their work when your schedule says they should.

Failure of the team or stakeholders to follow the processes you have implemented for your project is another communications related mistake. We write a 25 page process circulate it, post it in a central area and expect the team to not only read it, but decipher their role in the process, identify the actions they are called on to execute, and then execute them. Then we’re surprised when our processes don’t get followed.

Avoidance Strategies

The first piece of advice I would give project managers, the one that will prove most valuable in preventing mistakes here, is to avail yourself of the excellent training available in this area. Most of our communication is done verbally so concentrate on that area first. Don’t neglect the written word or presentations. Once you’ve addressed any training deficiencies you have in this area you can ignore the rest of the advice here; you won’t be making any more mistakes!

Until you can take those classes, here are some things you can do to address those mistakes. Always check for understanding after you have communicated an important direction. Don’t be aggressive or rude with this check. Sometimes the best way to measure the level of understanding is to simply ask the team member to repeat your directions, telling them that you are simply checking to make sure you have communicated clearly. Check what you hear against what you think you communicated and address any gaps in understanding.

Commitments are a special area requiring further action. You may have communicated very clearly with your team member, leaving no misunderstandings, but that doesn’t necessarily mean that you can expect your directions to be carried out. A commitment is a verbal agreement between you and your team member covering the work that team member will perform, and when they will complete it by. It is usually meeting the deadline where the trouble occurs, unless you have chosen the wrong person for the job. Always get verbal commitment to meeting deadlines for work you assign. Check first to make sure that the scope of the work is understood and ask if the duration estimate made for the work is reasonable.

Even when the work is clearly understood and you have a verbal commitment from the team member that they will meet the deadline, you’re not finished communicating. Issues can and will arise that can prevent the team member from meeting their deadline if they are not addressed. You can’t avoid these issues; all you can do is to have your team member communicate the issueto you as soon as they discover their deadline is in jeopardy so you can address it. To do this you must establish an environment of trust. The team member must know that they can come to you with the issue without facing any negative consequences. Using a "walk about” management style can be a great help in establishing an environment of trust. Ask each team member if they are encountering any problems that might impact their deadlines. If they report any to you that are beyond your ability to address, validate them and then escalate them to your sponsor, customer, or client. Explain your reasons to the team member if you can’t address the issue, or you feel the issue isn’t valid.

Work on software projects is more and more frequently being performed by off-shore teams, which adds another pitfall for the project manager: misunderstandings due to cultural differences. Do your best to educate yourself on the culture you’re dealing with and adapt your communications to accommodate the culture. Start by scheduling meetings so that everyone has a turn at being inconvenienced. Work the differing holidays into your schedule by creating individual calendars for each resource on the team, then blocking that persons holidays off on the calendar. Cultural differences that can act as filters on your communication must be addressed. For example, when dealing with cultures where deadlines and individual efforts are less important than team well-being you will need to communicate the negative impact a missed deadline will have on the team. There is plenty of literature out there to help you understand and deal with different cultures, make use of it.

Customers & Sponsors

Customers, clients and sponsors are the folks who pay the freight. We don’t give them directions to execute project work, they give them to us. It is our responsibility to ensure that the project’s deliverables and schedule meet their expectations and that is where most of us make our mistakes: our failure to manage customer/client/sponsor expectations. The way we manage those expectations is through our communications so failure to manage expectations becomes a problem for communications to fix.

One common error in this area is our tendency to hoard bad news. We encounter several set backs on the project that we didn’t anticipate – a required feature in the system has a hidden dependency on some other feature which we didn’t count on building, or someone is suddenly taken ill and we can’t make up the lost time. We do our best to keep the project on schedule and budget but simply can’t overcome the obstacle. Then, when it is no longer possible to meet the schedule, we inform our customer/client/sponsor that we will be slipping the schedule.

Executives need to be kept informed of project progress but are very busy and don’t have a lot of time to understand complex project information. Everyone has a slightly different preference for project performance information. We frequently either give our executives an avalanche of project performance detail which they don’t have the time or knowledge to absorb, or we give them information about project performance that they don’t want and fail to give them information that they do.

Avoidance Strategies

Treat your sponsor, executive steering committee, or client like a customer and treat your communication with them as part of the project’s deliverables. Like any other deliverable, you must gather requirements for this deliverable to ensure that it meets their needs. The simplest way to gather communication requirements is to do it at a meeting where you have all the executives in one room and can reconcile differences in requirements. You will have to get inventive where it is not possible to gather all the executives in one place to elicit their requirements. Try sending a menu of possible information and have them check off the items on the list they would like. Don’t treat unresponsiveness as an indication that executive doesn’t want any information; follow the solicitation up with a phone call or visit. Understand that the information you commit to communicate must be gathered, tracked, and updated by someone throughout the project so it is as accurate as possible.

You want to keep the information as brief as possible, so try using a "dashboard” or "scorecard” approach that gives the reader a brief view of most aspects of project performance. Here is a list of items to consider:

• Overall project performance (green, yellow, red)
• Performance to schedule (e.g. SPI)
• Performance to budget (e.g. CPI)
• Corrective actions implemented or planned
• Current project phase
• Quality performance (number of defects found, number of defects fixed, number of defects per unit of code, etc.)
• Top risks to the project and their mitigation strategies
• Change requests (e.g. number of changes received, number of changes approved, number rejected, total changes to the project in days of effort, etc.)
• Top issues

Use graphs and charts to communicate project performance information wherever possible. The advantage of this approach is its ability to show performance history – great when performance is improving, not so great when it isn’t. Include corrective actions where sliding performance calls for it. Keep the information brief when charts and graphs aren’t feasible. Avoid long winded narratives containing a level of detail no-one has time to read. Using presentation slides is a viable alternative when charts and graphs are not appropriate.

Make sure that your information is as accurate as possible and then explain to your audience how accurate the information is, how it is captured, maintained, and mined, and how it is used to create the chart or graph. The project SPI is a good example of where care needs to be used to educate your audience on how information is compiled. While the formula for calculating SPI is a fairly simple one, you need to explain that the work planned includes the work planned from the beginning of the project to present date, and likewise for the actual work performed.

Use Gate Meetings, Phase Exit Reviews, or Business Decision Points to mark the completion of one project phase and the beginning of the next. These meetings will communicate to the customer/client/sponsor/executive steering committee exactly where the project stands. Communicate the criteria that you believe is required to pass the gate to the executives in advance of your meeting. Do not ambush anyone at the meeting. Team members with key deliverables for the meeting should be informed in advance of the meeting and the role their deliverable will have (i.e. if their deliverable is not ready at meeting time, the gate fails). Hold a pre-gate meeting to flush out any dirty laundry that should not be aired in front of the executive. Know who the decision makers are/should be and then be clear on what the decision criteria is and what the possible decisions are.

The tips and tricks described in this article implement some of the best practices promoted by the PMI (Project Management Institute). These are taught in most PMP^® courses and other PMP^® exam preparation training products. If you haven't been certified as a PMP^®http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php. (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: