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.

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.

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, ...

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 ?

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.

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.

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.


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.

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.

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.

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.

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.

Monday, February 11, 2013

Communication crumbs

Communication is probably the most critical task in project management and not surprisingly is often one of the greatest challenge a project manager has to face. 
What is maybe less surprising is the fact that it is not only poor communication planning that can harm a project but also its overabundance.
I want to tell you a story.
Some weeks ago, upon the completion of a milestone,  a project manager in charge of a very complex technical project sent an e-mail to some of the project’s stakeholders, explaining technical details about the deliverable, details about technical solutions adopted and why they had been adopted, details about problems encountered during the deliverable realization and further step to be taken. It was a very well crafted e-mail. If you have had the time to read it you would have been aware of almost every aspect of the work packages, activities and issues related to the deliverable. 
The problem was that just a few stakeholders seemed to have found the time to read it. 
Someone marked the communication as important, put it aside meaning to read it later and eventually forgot about it. Someone else decided that the e-mail was too long, so preferred to be related by someone else that (maybe) read it. Some other stakeholder skimmed fast through the e-mail searching for the parts he/she could have been interested into. In many cases missing them. The only stakeholders that bothered to read the entire communication were the few really interested in almost all the aspects of that communication.
What do we learn from this story ? Two important lessons
  • Communication must be accurately planned and
  • Communication must be accurately targeted.

How it should be
Communication should be both efficient and effective and always on time.

Efficiency can be summed up in the ability to articulate complex concepts in small spaces and with few words or in a small amount of time. The aid of images and graphs is often required. The use of bulleted list is welcomed. The use of short unambiguous sentences a must. Redundancy must be banned.
if only you were touched by the idea that a sentence could be unnecessary, then erased it immediately or do not pronounce it.
In case the message, regardless of the type and of the delivery method, should be long and complex it would be a good idea to include a brief digest at the end. Before delivering it please consider if just the digest couldn’t be enough. There is no point in communicating a great deal of unnecessary information. It wouldn’t make the team effort’s more appreciated, it would reduce your probability to make a breakthrough in your audience attention.

Effectiveness can be summarized as the ability to deliver a message that can be easily understood and remembered. This is obviously better achieved with brief and clear messages with the characteristics mentioned in the previous paragraph. 
Be careful not to distract reader’s attention from what is really important. Even better do not include anything that it is not really important. You are not writing a poem or giving a lecture on the eighteenth century English literature. You just have to deliver a business communication.
Should your messages be too long and articulated, this could be a sign that your communication plan could be not well crafted. 
Consider a revision and try to shorten the communication interval or to split the current communication in two or more messages.

On Time communication should never be given too early and absolutely should never be given late. If a message is delivered too early the recipient could forget the communication details right when he would have needed them the most or he could archive the communication and eventually forget about it. Conversely if a message is delivered too late the recipient will find it absolutely useless and could call into question the value that the project manager gives to their relationship.

give everyone what they need and only what they need to know.

These are general guidlines that I have been comfortable with in almost any kind of communication (verbal, written, visual,...) and like all the guidelines it comes the time when a project manager has to breach them. Still I think that those occasions should be not very common.

What, When, Who and How
A good idea is to directly ask the stakeholders What kind of information they are interested in, When they want to receive updates and How. It is a small courtesy that will allow you to improve the effectiveness and efficiency of project communication and at the same time show your stakeholders that you care about their needs and you consider their time valuable.
Obviously this again is a general approach. Sometime an unexpected 3 hours intercontinental phone call in the middle of the night is necessary and not avoidable.
If interviewing stakeholders about their communication needs is not possible the safest way to proceed is to ask yourself Why a stakeholder should need a particular information and communicate just the informations for which you have found a sound reason. Chances are that if you identify the main reason for a particular communication then the When and sometimes the How will follow as a consequence.
This kind of information should obviously stored in the communication management plan.

I think that previous guidelines hold for reporting too. I fell like to add just a brief consideration. Reports, differently from other kind of communications, are about the past. Project management is about shaping the future. So take good care in reporting informations but do not put in it more effort than what it deserves.
For report being on time is maybe more important than for other types of communication. Reports are a snapshot of a project in a given moment. Projects evolve in space and time. So why should I need a snapshot about the project status on Monday afternoon if now is Friday morning ? Probably I will decide to skip this report and to read the next one and as a consequence I could miss some very important points. 
Project manager should proactively avoid this kind of problems managing communication toward and from all project stakeholders.

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