Showing posts with label share. Show all posts
Showing posts with label share. Show all posts

Sunday, February 24, 2013

Stakeholder management - start with collecting data


The stakeholder register is without doubt one of the most useful document in the management of a project. If correctly filled in and frequently consulted it turns out of the greatest help to the project manager in many situations.
As with many other project documents its contents should not be strictly a priori determined but adapted to current situations. Therefore we can say that there is no silver bullet for the stakeholder register, although some contents seem to be strictly necessary.

Date
It is essential to include an identification date for each stakeholder.
Since projects greatly benefit from an early stakeholders identification and that providing this informations as early as possible in the life of a project is an important project manager task, graphing stakeholders identification dates shows if the stakeholders identification processes have been efficiently and effectively conducted. An example is reported in Figure1. In the a part of the figure is depicted a poorly conducted stakeholders identification process, with identifications scattered all along the project time horizon. In the b part of the figure is represented an effectively conducted process.

Figure1.  a poorly conducted stakeholders identification process. b a well conducted stakeholders identification process.


Taking advantage of these data, the Project Management Office could take actions to improve the project opening processes or, if the case,  provide targeted training to project managers.
Including an identification date for each stakeholder is also important to data collection purpose from other project documents.

Code
It is very important to enter a unique identification code for each stakeholder.
This is necessary to be able to uniquely and concisely identify each stakeholder within project documents and to include references in documents eventually shown to third parties without disclosing details.

Business informations
Informations regarding stakeholder identity such as name, surname, company, department, supervisor, business role, ...

Role
What is the stakeholder main role in the project.

Contact informations
Business and/or personal phone numbers, e-mail accounts, addresses, social network accounts,... Of course, all information must be collected, stored, protected, retained and disclosed strictly under terms of law and used accordingly  to the stakeholder’s wishes.
Ask the stakeholder which are his/her preferred communication means and add this information to the register.
Do not underestimate the potential of using social networks for business communications. Sometimes there is mistrust with respect to these instruments, but they are here and they are here to stay. So why not to take advantage of them ?

Why
A detailed explanation of the main reasons why someone has to be considered a stakeholder.
Only understanding why someone is important for the project (or why the project is important to him/her) we can truly understand his/her role and effectively manage the relationship.

Expectations
If possible ask each stakeholder what are his/her expectations about the project in terms of benefits, gain, loss, career, cultural enrichment, ... if this is not possible try to imagine and figure out by yourself the main reasons they are in the project.
The same considerations should be applied to team members (they are also stakeholders) and as far as possible assign them project tasks furthering their inclinations.

Interests
If possible ask each stakeholder what he/she is more interested in, relatively  to the project scope and activities.
Take care in assign them project tasks or activities furthering their inclinations and/or in communicate them update regarding the interests they have expressed.

Attitude towards the project
As a first step divide internal and external stakeholders in four main classes:
  • Positive passive stakeholders that are positively influenced by the project 
  • Positive active stakeholders that can positively influence the project. 
  • Negative passive stakeholders that are negatively influenced by the project  
  • Negative active stakeholders that can negatively influence the project.

Figure2. A stakeholders classification. In green positive stakeholders and in red negative ones.


However reality is often more complicated than that and only these categories may be insufficient for accurate management. You are advised to attach a description of the attitude shown by each stakeholder towards the project and the possible reasons.
The formalization of information often leads us to a deeper analysis, often providing new and interesting ideas.
For example, we may find out that a negative active stakeholder shows this kind of behavior just because we have not been sufficiently clear in communication about the impact that the project could have on his daily work.

The sections Why, Expectations, Interests and Attitudes are linked together in a kind of feedback loop, as those that can be seen in Digital Signal Processing filtering and depicted in Figure3.

Figure3.


Every informations contained in one of these section can be used to add proactively add informations to the others.
If you know Why someone is a stakeholder, then you can start to identify his/her Expectations and Interests. Once you know his/her Expectations and Interests you can add other reasons for considering him/her a stakeholder, adding information to the Why.
When you have discovered Why someone is a stakeholder and what are his/her Expectations and Interests then you can identify his/her Attitudes toward the project and then better clarify his/her Expectations and Interests.

Try to express the Why, Expectations and Interests section content as bulleted lists. In this case assign a score to each entry to asses its importance and for prioritization purpose. You can find some consideration on the subject in this my previous post.
The post was originally conceived to explain risk qualitative analysis. However its content appears perfectly applicable also in this case.

Influences
It can be seen as an output coming from the complex relationship between the Why, Expectations and Interests sections.
It is a list of project phases, area, activities, … where the stakeholder could or would  exert his/her influence.

Buddies
It could be useful to list other stakeholders that have similar Expectations, Interests, Attitudes, Influences,...yes here is one place where you benefit from having assigned a code to each stakeholder.

Model
It is often useful to characterize each stakeholder through the use of a model, to qualitatively assess his/her influence on the project. As an example it is possible to assign a score to the influence a stakeholder is able to exert, to the power that he/she is able to manifest, to the complexity of requests that he/she is able to pose ...
I recommend not to go further than to characterize stakeholders with 2 or 3 attributes and assign scores as set out in this my previous post.

Communication requirements
For effective and efficient project communication planning is fundamental ask to each stakeholder what kind information they are interested in, the preferred mean of communication and the frequency of required updates.
More details on this subject can be found in my previous post.

And...
The stakeholder register compile is an activity that has to be performed at the very beginning of a project, even if is clear enough that it is a document that could (and probably will) be updated during subsequent project processes.
New stakeholders can be identified, It may be necessary to change or update some records, stakeholders may suddenly no longer have any kind of relationship with the project ...
All changes to the stakeholder register should be justified and all the document versions should be kept and made available during the time horizon of the project on request.
At the end of the project every version will be permanently stored in project documentation, without exception.

I have provided an example, a very simple one, of a stakeholder register MS Word 2007 template.
If you want to try it, please follow this link
Let me know what you think about it and please let me know if you feel the need to modify it.
I would be glad to incorporate suggested modifies in the original, so that your experience could also help other people...and me.



Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Wednesday, December 12, 2012

Change and people without choice


Projects are not static entities residing in a never changing environment. 
As a matter of fact, they are more similar to growing organisms that must adapt to a changing habitat to survive and thrive. So we do not have to fear changes.
Changes are right, changes are good, changes work. 
What we really have to be scared about are unnecessary and/or uncontrolled changes. These are real dangers, the agents that could doom your project transforming it from an honeymoon with your stakeholders to a never ending hellish journey. 
So it is mandatory that a sound and effective change management strategy be in place and be followed by project managers and project management team members throughout the project execution. 
An important aspect of change is obviously communication and I would like to focus on communication between the project manager, or the project management team members, and the people who will be passively affected by the change without being able to do anything about it. I am talking about the less important stakeholders of the project, those who can exercise just little influence on constraints or objective, those who haven't much power or simply are not much involved in the project. 
Probably in a perfect world this should not happen but I have witnessed some of this circumstances and I have learned what I think is an important lesson. 

You have to take good care in communicating changes to these stakeholders and never base your communication strategy on the assumption that they will agree with the change or that they will be prone to accept it just because they cannot avoid it. 



So it is important that you start with the right foot here and I think that the right foot to start with is explain WHY a change is necessary, followed by HOW you and your team will take care of the change and finally WHAT is the change. 



I suggest you not to do it the other way round. 
People are more prone to accept and listen your point of view if it is well motivated, moreover in this way you will be able to prove that a change is ineluctable before generating any kind of resistance in your audience. 
In this way you are not commanding your stakeholders but you are sharing your project insight with them, you are showing concern for their role in the project and you are managing their expectations. What a project manager should always do.
You are now proposing a solution, not a problem. 

I suggest you to view this presentation by Simon Sinek about starting communication with why. I found it extremely interesting and inspiring. It is a video more or less 20 minutes long but I think is worth to be viewed.

Another important wisdom is to show data that explain accurately the WHAT part of your communication. 


It is not enough to talk with people, you also have to sustain your point of view with facts and prove that everything is under control. People are usually more afraid of the unknown than they are of changes, I have found.






Licenza Creative Commons
Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.