Honing stakeholders’ analysis

Everything related to the project starts and finishes with stakeholders. In most of the cases, they produce and/or consume information; however, they take decisions on the supplied information.

In the new version of Prince2 the former “Communication Plan” has evolved into the “Communication Management Strategy”. This has been modeled on the OGC “Corporate communications policies”. This post starts an analysis focused on the best way for sharing some considerations about the feasible techniques for transforming a working relationship into a fruitful collaboration. The desired result is to share a logic for building / tailoring tools that allow the central position of the stakeholders in the project’s documents.

Understanding their needs

These are some areas where to investigate and honing the tools and processes:

1. Mapping people and then the potential evolutions of their attitudes and interests
2. Be prepared to understand which sort of information they trade in.
3. What is their influence on the project? Whatever is the single result, it has to be ranked, leaving the possibility of changing it during the project’s life.
4. Have they an interest or detriment on the project? If it is the negative one, is it possible to change their opinion?
5. Understand their needs for releasing or receiving information:
   1. Format (report template)
   2. Process: how the information is formed and/or traded?
   • Official meetings (e.g. Steering Committee)
   • Technical reviews (e.g. quality, “peer review)
   • Informal meetings (e.g. phone calls followed up by emails)
6. Tools to be used for delivering the information (e.g. MS Project print-out)
7. Timing (scheduling)
8. Energy/Time required (how long does it take for being produced/consumed?)
9. Profiling (Any targeted communication is going to point out a specific group – a sort of distinction from all other stakeholders)
10. Quality. Finding some values for measuring the output (see post ).

Mapping people in their environments

Any information regarding the project has to be dynamic (i.e. related to the time it has been produced and/or recorded). One of the most difficult things to do – at least for me – is to be ready to accept and then exploit changes in the people attitudes. Often, it is much easier to go on with our established truths. Once friends and enemies are tagged, all energies are dedicated to work on real things. Items can be evaluated using objective criteria.

There is a flaw in this attitude; in order to make “real” things (either functions or reports) information is still needed. Some data are essential in order to grant the necessary quality others are necessary for presenting the result in the best possible way.

People with technical background (e.g. with no specific training in sales and or negotiations) usually tend to focus on the delivery, with less attention to the factors that can influence the acceptance.

Conclusion

Technologies are to be viewed as ancillary of the business processes; insofar they have some unique aspects. Therefore, the logic used for building tools needs to be robust enough to withhold the scope (capturing, ranking and managing any bit of information) during all different phases of the project.