8.3 Communications Strategy

< Day Day Up >

Take a moment to think about how you want your project to be perceived by stakeholders, including beneficiaries and others not looped into your daily activities. This should be easy to do if you consider past experiences where you were a project beneficiary subjected to a personal computer (PC) replacement, being homed into a new server, or getting a new communications package for local area network (LAN) or Mainframe access. I will wager that experience was frustrating and possibly quite annoying. You may have had to rearrange your schedule to accommodate an installation. You may have suffered a service outage, or a temporary degradation in service, until everything got fine-tuned. You may have had to change the way you did things, such as learning how to enter hours worked in a new online timesheet system. You might even have been moved to a new floor or building and had to change your daily commute and find somewhere else to shop or get lunch. Under these circumstances, the biggest complaints you and your peers shared were probably:

What are they doing?
When are they doing it?
Why are they doing it?
How will it impact me?
How long will it take to get used to these new attributes of my work experience?
When will the supposed benefits be realized?
Whose idea was this, anyway?

Do any of these questions sound familiar to you? Now, as project manager, you are on the other side. You should consider whether or not you want to address these issues should they arise as a result of your project. How would you do that? Would you set up a Web site? Would you send group e-mails, such as a newsletter? Would you hold regular status meeting with key members of the community impacted by your initiative? Would you say all these activities would take time, money, and resources that you do not have, so forget it?

Part of your communications strategy will be based on this conversation you have, particularly with your sponsor. The practicality of launching an information campaign should probably be evaluated against the risks associated with taking no action in this regard. Probably the best way to review this risk is to assess the degree of change your project will create in the beneficiary community. The greater the change, the more compelling it is to get something out there to the public. I have seen the whole gamut, up to and including a pretty impressive marketing campaign designed to familiarize people with the look and feel of the facilities and technologies being rolled out in a new location into which they would move.

Because we are looking at complex projects in this book, I think it is fair to assume that you need to do something. I would look to hand that problem to someone else, for instance, in Human Resources (HR), Facilities Management, Corporate Communications, or Corporate Training, depending on the type of project and the size and nature of the impacted constituencies. Meet with these people and articulate your concern that your team lacks the funding or skill sets to effectively educate beneficiaries as to the pending changes in their workplace, and let them handle it. Most corporations are sensitive to these matters.

Assuming that this tactic gets you off the hook as a public relations manager, you still are responsible for presenting your project via communications of some sort. Except for the most detailed and arcane design, implementation, and operational support documentation, you should assume that anything else that escapes the gravitational pull of your core project team could end up on anybody's desktop. Not that I would censor each document as though it will be read by your CEO by the close of business tomorrow, but you never know.

What you do want to keep in mind is that you want to convey an image that instills confidence, respect, and cooperation to the degree possible in today's world. In other words, you want your project to look crisp and together, even if things are tangled and snarled like December's cross-town traffic in midtown Manhattan. To that effect, I created Exhibit 2 to outline the communication strategy you should tout and enforce to the best of your ability.

Exhibit 2: Documentation Do's and Don'ts

Publish documents in a timely manner, and keep them updated.
Style and content must be net. Clarity, precision, and relevance are key.
Avoid techno-babble, MBA-speak, and ambiguity.
Focus on names, dates, and project impact or significance.
Use strategic documentation (i.e., dealing with scope or design, and should be explicit).
Touting technologies is irrelevant, if not misleading, from a project perspective.
Explain technology with the "feature, function, benefit" approach (Chapter 13).
Use it or lose it. Unrefreshed content goes stale.
Aged or sloppy documentation creates a negative impression.

The credibility of your management and other aspects of the project can be tied to a successful documentation strategy. Documentation, or the lack thereof, can be used for or against you, so take heed.

< Day Day Up >