Avoiding Communication Breakdowns

Larger projects require more detail than smaller projects. Larger projects, of course, have more stakeholders because of the size and scope of the project.

We know, we know. That's like saying it'll take a long time to swim to Hawaii. The point we're making is that the larger the project, the larger the opportunity for failure. The larger the project, the more demands you have on your time for planning, controlling, and ensuring that the project is executed as planned. And the larger the project, the tougher it is to communicate effectively, and the more critical it is to communicate effectively.

SlUD^ We know because we've been there. One of the largest projects Joe ever pf! \ managed was the development of an e-mail interface for nearly 40,000 users ^mtjSm worldwide. The project involved directors twice Joe's age and income, pro. ay grammers from around the world, and stakeholders that Joe had never met face to face. In addition to the development, testing, and rollout of the new application, Joe had to coordinate all the training materials, training classes, dual support, and interoperability of two systems over six months. Joe also had to handle all the logistics of testing, versioning, and making hot fixes. It was the most fun Joe ever had on a project — really! Communication was a crucial element that held everything together, and so was a good attitude. But he also discovered that he would have done a few things differently, especially in the area of communication.

Facing the risks of communication meltdowns

The risk of a communication breakdown is that problems that could have been easily solved haunt your project. Here are some risks of miscommunica-tion, in order of severity, along with possible solutions:

1 Problem: Wasted time. You kill hours every day answering the same question over and over and over. It'll drive you mad. At least, it drives us crazy, and because we're writing the book, we've listed it here at the top of the list.

Solution: Take the time to communicate your plans with the stakeholders and then make those plans available through a Web site. You can save so much time if you use the technological tools available to you. We recommend creating an FAQ (frequently asked questions) for your project and posting it on a project Web site. Include the Web address of the FAQ as part of every e-mail you send. When folks ask the same old question, answer the e-mail by directing them to the FAQ for a whole list of project questions and answers. Add new questions and answers to the FAQ as they arise.

^ Problem: Wasted money. Of course when you waste time you're going to be wasting dollars, but this fact also translates to your programmers. Software creation is time intensive; if the programmers on the project team are creating the wrong stuff based on miscommunications, you're not going to be happy. You might as well throw money in the gutter — it's essentially what you do when programmers waste time on useless code and have to start over.

Solution: Require the programmers to e-mail you weekly status reports that include "accomplishments for the week." Hold regularly scheduled team meetings with a standing agenda item of progress and issues.

Over time, lost time and money have a negative impact on programmers' morale, confidence in you as a project manager, and desire for accuracy. When people race to meet deadlines, they make mistakes.

^ Problem: Frustration. Communication breakdowns, whether they're your fault or not, frustrate you, your project team, stakeholders, and the end users. When these people get frustrated, they're going to vent, steam, and grumble about the project. This, of course, leads to more complaints, gripes, and general unrest.

Solution: You can never completely stamp out frustration, but you can manage it. Be proactive by being aware of morale problems and frustrations before they get out of hand. Never assume that people will just get over whatever issue they may have. If you see a problem, address it immediately so that mole hills don't become mountains.

^ Problem: Lack of confidence. When a stakeholder sees that you've directed your team to do something that's not included in the project, or you've directed the team to leave something out of the software that should be included, the stakeholder won't be pleased. But, perhaps more importantly, he or she will begin to wonder whether you're capable of completing the project according to specs. Clients wonder whether you've made this mistake because you can't stand up and tell team members what they're doing wrong or whether you're afraid of hard work. Maybe they wonder whether a miscommunication is the source. We don't know all the things they worry about, but we do know this — they always wonder what other mistakes are lurking in the software.

^ Solution: Demonstrate your leadership skills by taking accountability for your miscommunication. Swiftly step in to perform damage control and rectify the situation. The specific steps you take will depend on the severity of the problem.

Managing communications across the enterprise

In the massive project we discuss in "Avoiding Communication Breakdowns," the communication between key stakeholders was planned in depth for months. Where the project broke down was when the project team began to roll out the software to pilot groups around the world. The end users of the software had gotten swept into an undercurrent of rumors and speculation.

The failure in communication was that, as the project manager, Joe had neglected to consider the impact of the software on the end users. Everyday users knew the change was coming, but they didn't understand what the change meant for them. As a result, they gossiped, spread rumors, and were generally filled with anxiety. Additionally, the sheer size of the project left Joe with a daily flood of e-mail and voicemail that slowed progress. Joe had never planned how he was going to squelch the cultural achievability issues of the software among members of the organization.

Communication can break down anywhere in the process and with any segment of people involved in the project. Never underestimate the importance of communication, even with those people you don't have direct contact with. Ensure that you have strong communication throughout the project to all the stakeholders that are affected.

Here's what you can do to avoid the problems we've dealt with:

i Educate end users about the changing software and take steps to ensure that they understand what's coming to them. End users always need to know how the software is going to change their day-to-day job functions.

Sure, your project team may do a fantastic job creating, distributing, and training the organization on your software creation, but you have to get buy-in if you want to avoid headaches.

i Maintain proper communication levels. In a large project you can easily fall victim to a common phenomenon of focusing all your attention on the key stakeholders. But you must take extra measure to communicate to all of the appropriate stakeholders as the project moves towards completion. Figure 4-1 shows the typical curve of communication in an average project.

The traditional curve represents all the communication that happens at the beginning of the project: the project charter, the kickoff meeting, the scope management plan, and the stakeholder analysis. And then you and the team disappear to plan, control, and execute. And what happens? The focus is on doing the work and not communications — until the project nears completion as represented at the end of the curve. Oh, the end is near, so excitement (or panic) drives the communication.

c o

Figure 4-1:

o

Communi-

'E

cations

E

typically dip

E o o

during the

o

project

'o

execution

O-

processes.

Project launch: High level of communication

Project launch: High level of communication

Project completion: Communication increases

Project execution: Communication dips

Project completion: Communication increases

Project execution: Communication dips

Project Timeline

The ideal communication curve is depicted in Figure 4-2. Communication is high at the beginning of the project, dips slightly as the project team does the work, peaks at evenly timed increments for status reports, and then begins to increase as the project nears completion. Of course, this pattern looks logical on paper, but without a dedicated effort, it's difficult to implement out there in the real world.

Project launch: High level of communication

Communication increases at project status meetings and milestones

Figure 4-2:

Communications should reflect the project progression.

Project launch: High level of communication

Communication increases at project status meetings and milestones

Project completion: Communication increases

Project Timeline

Project completion: Communication increases

Project Timeline

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment