Preventing Project Failure

Project Managers are often stuck between responsibility for a project and authority to make things happen on that project.

I’ve pulled together a few useful tools and a process that can help you identify and mitigate for communications in client organizations where you have little or no access to key stakeholders.    These tools are geared to situations where the PM is not going to be able to change the communications, but will be able to do the next best thing which is to understand the communications and plan for them in the project.

Using the Organization Chart,  map out the facts about each project stakeholder.      Don’t limit this to just internal project stakeholders.  Remember that the PMBOK defines a stakeholder as anyone who is affected by the project.  Don’t forget the everyday user or the outside executive on the periphery.

Here’s a sample stakeholder analysis chart I put together for one of my projects.

Stakeholder Analysis Sample - Click to Expand

This stakeholder analysis is concerned with stakeholder influence, importance and attitude.  If you do modify the questions, keep them simple, so that the tool remains efficient and usable.  You can adjust this to your environment.

Do a conflict assessment of communications. A conflict assessment will enable you to understand the broader environment in which your stakeholders operate.  There is a great checklist tool online that walks you through the right questions.  Not all of these will apply but they will get you thinking.http://www.beyondintractability.org/checklists/organization_intermediaries.jsp?nid=5258

Do a Communications Breakdown Structure and compare it to the Org Chart

A colleague and I were lamenting about how difficult it is to manage communications within the client organization.   Both of us encountered situation where we assumed that clients were communicating project status to other key stakeholders we did not have access to.  In both cases, communications were not occurring and in both cases, the client who was not in the know came down really hard on our projects.  So we came up with a new idea ‘ the communications breakdown structure’.  This is basically a diagram, similar to a work breakdown structure, that elaborates assumptions about communications.

This is best demonstrated with a a comparison. The organization chart looks like this.

Sample Organization Chart - Click to Expand

You can compare the org chart to the communications breakdown structure.

The Communications Breakdown Structure starts with how project communications will flow.  It assumes that the Project Manager is the start point.  In this example, the Project Manager communicates a Project Status to the Executive Sponsor and the Project Sponsor.

Communication Breakdown Structure - Click to Expand

This chart makes visible the assumption that the Project Sponsor will communicate to the Project Stakeholder (the red line). However, many times, this is dangerous assumption.  Doing a chart like this will enable you to visually see the possible breakpoints like the one between the Project Sponsor and the Project Stakeholder.   Anytime there isn’t a direct line from the Project Manager to any stakeholder, recognize that an assumption exists and raise that assumption (there are suggested ways to do that below) during the project planning phase.

Once you have performed these tasks you’ll probably have much more insight into both the environment and each stakeholder.   You’ve probably surfaced some risks that you’ll need to mitigate along with assumptions about the project that you need to document and raise with the project sponsors.    Here are suggested steps you can take to help you raise the issues with project sponsors.

Incorporate what you’ve learned into the project structure

1. Add the risks to your risk register.
   

   Risk Example: Project Sponsor may not communicate to Project Stakeholders.
   

   Mitigation Example: Project Manager will distribute project status reports to all stakeholders.
   

2. Add an assumption to your project plan that all stakeholders will receive project communications.
   

   Assumption Example: All stakeholders will receive the Project Status Report on a weekly basis.
   

3. In your communication plan, specify that project status will be communicated to all stakeholders.
   

   Standard Project Communications Example:  All project status reports will be communicated to project stakeholders on a weekly basis.
   

4. Include the key stakeholders as members of the Change Control Board. Include those stakeholders with whom you don’t have access in the change control board.   That way they’ll be aware of the pulse of the project and have a say in each change in the application.
   

Take one day out of your week to do this analysis.  It will be well worth the effort .

• • Comments [3]
  • Tags [communication barriers]
  • Categories [Communications]