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…