ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs Project Communications - The Good, The Bad and The Ugly (3 of 3)
Tuesday, 30 October 2007 03:46

Project Communications - The Good, The Bad and The Ugly (3 of 3)

Written by 
Rate this item
(0 votes)

 We have all been on projects where an understanding different stakeholder groups becomes a ‘touchy-feely’ process.  You have a gut feel for their tolerance for change, commitment, ability to influence and what they view as important.  Most of the time we are wrong but if we had some real data for these areas, then we could establish effective communications and begin to understand what challenges faced us during our project time line.

One project where the Project Manager reflected that the V.P. Finance has been very quiet in the initial meetings, the initial perception was he was not opposed to the project.  About two months later, just before the kick-off, there seemed to be a growing opposition.  At the last minute he did not approve the project to proceed.  The Project Manager regretted he didn’t spend more time developing a key stakeholder analysis and a corrective action plan.
 
Have you had similar stakeholder gaps?

The analysis of stakeholder and organizational requirements can be used to identify the degree of project related change required (both incremental or fundamental) and to diagnose required changes.  This gap analysis will provide a process for examining the differences between where the stakeholders are and where they need to be after the project is completed.  Though “gut feelings” are many times correct, there is nothing better than supportive data.  The difference between actual and desired future states indicates potential areas for planned interventions.  Once these differences have been identified, it will be important to assess priorities to guide the project communications activities.
 

 
You can see in this graphic the stakeholder group in the analysis on the left is both committed and have a high tolerance for change.  On the right, a lot of the stakeholders in the analysis felt the project was very important but none had the ability (organization or decision making structure) to influence the change.  The only person who had the ability to influence identified the project as the lowest level of importance.  This analysis provides great insight to the project management team to use communications as a method of positive change.
 
In one project, I remember there was a stakeholder group showing a lot of resistance to the project.  They were vocal and our project management team was all leaning on me to “do something.”  After a preliminary analysis, I found that they had very little ability to influence and a low tolerance for change…but they thought the project would eliminate their jobs.  Actually this was not true and with a clear picture of how to structure our communications with them, they quickly turned their energy to helping with the success of the project.
Some additional data points you could consider are:

  • Chart the boundaries between key organizations and the their managerial control for a successful project.
  • Chart the decision-making patterns between and within relevant organizational units.
  • Test for key organizational assumptions, principles and constraints.
  • Identify role definitions derived from stakeholder competencies.
  • Compare different locations among the impacted stakeholder groups.

 

Don’t forget, you don’t know what you don’t know.  Spend the early days checking and double-checking your stakeholder matrix, their needs and chart your analysis to validate your strategy.
 
Are more detailed documented requirements better?
 
Projects are driven by requirements and we have all tried to document the project requirements to cover …well almost everything.  Communications can open up the concept of collaboration that just might not require everything to be initially documented down to the nth degree.  As we approach using agile project methods, communications strategy should include the customer/stakeholders to work in closer where the documented requirements are at a higher level and the more detailed requirements are identified and documented in a collaborative environment.  This approach works in a development projects but is becoming increasingly used in other projects where detailed requirements are hard to define.  Increased collaboration should be identified as part of your communications strategy.  After the detailed requirements are developed in a collaborative environment, and then you perform a stakeholder analysis, you should beam with pride as you view the high ratio of stakeholder satisfaction.
 
Try it…you might like it…
 
Please share any examples of how ineffective communications have caused setbacks in projects you have participated in.  Also, identify a solution that could have been implemented to prevent this problem from happening.
 
In addition to responding to this blog…you can also contact me directly at This email address is being protected from spambots. You need JavaScript enabled to view it. to discuss your specific project communications related questions or needs you might have, or visit my new blog and website www.virtualprojectcommunications.com.

 

Read 6464 times Last modified on Thursday, 22 November 2007 13:43
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 569 guests and no members online

Got something to say?