P2 tip #5: Anticipate issues

15 06 2011

As P2 professionals, we bring a different perspective and skill set to a project team. While others are in the mire of technical methodology and data, we stand slightly outside the technical work and are well-positioned to offer insight that may not come from anyone else on the team. So speak up! Although our primary responsibility is to communicate effectively with the public to support the process, we also have a responsibility to anticipate issues that others may not see.

Our unique perspective can be traced to differences in right brain/left brain functions of planners, engineers and communicators. It may also come from our greater level of attention to how something may appear to the general public and whether information is clear, logical and understandable. I consider myself the first focus group for information … if I can’t make sense of it, how can I expect to explain it to stakeholders?

Moreover, as communicators we should be looking ahead at potential issues to help the team address them early. Being proactive in anticipating issues allows time to gather information or work with stakeholders who can be opinion leaders. Early groundwork can pay dividends later when controversy arises. If nothing else, the project team has already thought through a range of responses and it should help avoid the team going into panic mode.

Anticipating issues is an ongoing process during the life of a project. An initial analysis should be part of a public involvement plan, but it may also fall under a project risk analysis, situation analysis or stakeholder analysis. There are always changing conditions to address. Look ahead and think through reactions and consequences each step of the way.


P2 tip #3: Set agendas aside

1 06 2011

Complex and controversial projects are ones that are surrounded with many different voices and opinions; there are many factors to account for and countless options to consider. For this reason, it is important to set agendas aside. The guiding principle for projects I have seen come to successful completion is, “Do what’s best for the project.”

Doing what’s best for the project means taking a hard look at the technical data to see the story it tells. It means letting go of personal inklings or biases to really pay attention to the direction the data points toward. Once the team identifies the trade-offs between various options, it is time to present the options and get feedback on what trade-offs are most acceptable to the community.

An awareness of agendas at all levels (political to grassroots) is needed to effectively communicate with stakeholders and address a range of issues. However, because agendas will never square up and spending government funds on one group’s solution over another solution because of power and influence is unfair, the project team must examine the data in a clear and transparent way. The project purpose, methodology and results should form the basis of decisions.

This does not mean working in a vacuum or being free from political influence … there is a time and place to understand and analyze political will. But the data (and how the data was derived) must stand up to public scrutiny. For as dry as technical work can be to describe, there must be a logical and compelling story within the technical analysis.  And when the project team reaches an impasse where we don’t know what values and impacts to choose over others, it’s time to seek stakeholder input grounded in the presentation of well-researched facts.

P2 tip #2: PI takes the whole team

26 05 2011

If you were to draw a picture of how public involvement (PI) functions on a project, what would it look like? My best answer to this question is to state what it would NOT look like: PI as an appendage, an add-on, a group the team goes to in crisis for specific things …. “We need a meeting!” “We need a newsletter!” “We need you to go meet with this stakeholder to find out why they don’t like x, y or z!”

Although PI practitioners are responsive problem-solvers and we can do all these things, I prefer to view PI staff as facilitators that enable the team to communicate well with a variety of stakeholders. We are the resident experts to help the team communicate complex information and prepare them for their own technical and stakeholder meetings.

The medium is part of the message, and to send PI staff to cover meetings with various stakeholders sometimes sends the wrong message. The project manager, design engineer or other technical specialist must be present in the room for specific discussions that influence decisions. While we might have great interviewing skills and can explain proposed plans as well as anyone else on the team, having the actual technical specialist or decision-maker in the room sends a powerful message and changes the tone of discussion.

And so, PI takes the whole team; it cannot be delegated out to an informed but independently functioning individual or group. Every person on the team has a role in communicating with stakeholders; PI staff is there to help the team be successful in how it is done.