Perception and project management processes value

Perception is a funny thing; this, if nothing, I have learned in my life.

It has never happened to you, to involuntary hurt someone else’s feelings, just by sending him/her one e-mail, which you thought was neutral? On the other hand, have you ever been upset by a friend’s humorous comment, that, in the author’s intentions, was meant to be no more than a joke?

If this is the case, as I guess it is, you know well, what I am talking about.

Different people perceive the same things in different ways. We have talked about that in an older post.

Sometimes this attitude has to do with one’s culture, sometimes with his/her educations, some other times, simply, with temporary circumstances. You just can say.

Therefore, there is no such a thing as an objectively perceived reality, but rather, we have to cope with many different recognized ones. Luckily, this bunch of perceived realities often overlap enough, to grant a sufficient interoperability margin. The only things that cannot be misinterpreted or disguised are objective data.

The same pattern applies also to project management processes.

The dichotomy, here, is about the value that project management processes ensure and the value that the project’s stakeholders perceive. Please, take a look at Figure 1.

Figure 1.

On the y-axis, there is the value that the project’s stakeholders perceive as granted by the project management processes. On the x-axis, we can find the value that the project management processes deliver.

The 45 degrees line is the place where the perceived value matches the delivered one. The line is the project manager’s Shangri-La, the place where he/she will have to place. 

Criticism zone

The criticism zone is the region under the 45 degrees line. In this zone, the value delivered by project management processes is greater than the perceived one.

The stakeholders see the project manager’s efforts as wastes, as expenses to be cut as soon as possible and, therefore, no effective project management is possible.

The project manager has to get out from this zone as quickly as possible, trying to reposition the stakeholders’ perceptions on the equity line. Such an objective is not an easy one. There are no ‘tricks of the trade’. 

The only possible way to reconcile the provided value with the stakeholders’ expectations, is a constant and well-crafted communication, based on sound and objective data.

Esteem zone

The esteem zone is the region above the 45 degrees line. In this zone, the value delivered by project management processes is less than the perceived one. The stakeholders tend to see the project manager as a kind of wizard, an almighty presence with the ability to fix almost everything. 

Even if the permanence in this zone is far more pleasant, than being stuck in the criticism zone, still, the project manager has the due to reposition the stakeholders’ perceptions on the equity line. 

Why? Well, because taking more credit than you deserve is not fair, in the first place; and because, in the long run, it is a dangerous game. 

My grandfather used to say, “A donkey can dress up like a horse but, sooner or later, it will bray”. 

If you regularly fool your stakeholders’ perceptions, what will you do when you will have to rely on those perceptions, and you will find them spoiled by your management style? 

Again, the only possible way out, is a constant and well-crafted communication, based on sound and objective data.

The line

As we have already suggested, the 45 degrees line is the place where the project manager should stay.

Here, the perceived and the delivered value match. 

As we can see in Figure 1, three different zones can be identified on the line.

The minimum zone

The project management processes in place do not deliver great value, but this is crystal clear to all the stakeholders. They know what the project manager is up to, and if they feel like, they can ask for processes that are more valuable. 

Remember that you do not have always to be number one. Maybe, the value you are providing is good enough, for the project at hand. 

The minimum zone is adequate for small projects, characterized by short schedule, low budget, few people and few uncertainties.

The standard zone

The project manager is providing a standard level of value, with the management processes in place. Everyone knows it. No one can argue that the project manager is wasting money or is underestimating the effort required.

The premium zone

The project manager is providing great value, using complex and articulated processes. Still, everyone knows it. If the stakeholders require less effort, they will do it on a real data basis, and not just relying on perceptions. They will know that they are going to trade money with control.

The premium zone is right for big projects, characterized by long schedule, very high budget, many people and many uncertainties.

If you want to be considered a "project management superstar", this is the place where you want to be, not the esteem zone.
Even if, sincerely, my advice is always to provide the value that is required for a good management style, without artificially raising the stake.

Bottom line

Do not pretend to be a horse if you are a donkey and do not pretend to be a sheep if you are a lion. Play fair. Align the stakeholders’ perceptions to the value you are providing. Let the stakeholders decide if you are providing the value they expect from you, on real data basis and not on perceptions. In the long run, this will pay, no doubt about it.

Maybe they will not clap their hands at you, but sure enough, they will remember you when the next project is in sight.

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

Project Management crumbs on Flipboard

An old China said states “that you may live in interesting times”.

The ones we are living in surely are. Especially for what concerns new technologies and all the new communication opportunities they offer us.

Cloud computing and cloud data storage, writing documents cooperatively with native version control, blogs, social networks, smartphones, tablets, your data always with you, cheap phone calls over ip, Google hangouts…bring us possibilities that seemed unimaginable just five years ago.

In the same time we are facing new problems or old problems whose historical solutions are no more solutions at all. I am talking about security and privacy issues just for mention a couple.

I would not go as far as to count myself in the group of those guys called “early adopters” but surely I am one “early tester”.

I like to try new things but I balance my  appetite for innovation and novelty with an eye to the long term sustainability, security and privacy issues, opportunities offered, efficiency and effectiveness.

Particularly I am interested in all those applications that can help dislocated teams to cooperate more efficiently and in applications that can help everyone to get and sum up new informations and ideas.

So, the step from this blog and the associated Google+ community to a Flipboard magazine seems natural to me.

This blog will continue to be my main and favourite interface but at the same time I will add the most reviewed or appreciated articles also to the Flipboard magazine. Consider it a kind of best of collection.

So, if you will, you can also have the main pmcrumbs posts delivered to your smartphone or tablet in the form of a Flipboard magazine.

The magazine name?

…Well…project management crumbs brush...obviously…

Bye.

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

Stakeholders management - Join them in their cognitive space

Have you ever been stuck in what seemed a never-ending meeting, with a bunch of stakeholders on the war footing, stubbornly defending their positions and not seeming to get your point? If you had, I guess that the thought

Why these people seem not to understand...it’s so easy, so obvious...

must have passed through your mind at least once.

Well, Are you sure that it was so simple and obvious for them, to share your point of view?

Let me play a little game with you

Look at the image below for a couple of seconds. What do you see?

Figure 1.

Probably you have seen a belle epoque Parisian dancer or a grumpy old lady. Now, please, take a look at the picture again, and try to visualize the character you have not seen before. Have you seen it this time?

The chances are that you have not. Please, pay attention to the figure below.

Figure 2

Now look again at the image in the first figure.

Can you see now both the characters? Can you see both the belle epoque Parisian dancer and the grumpy old lady?

The cognitive space

Well, this is what sometimes happens to people during discussions.

Someone immediately sees the dancer, and someone else sees the old lady; that is because different people look at the same things from different point of views, from different perspectives, and with different sensibilities.

So it is not that your stakeholders are strenuously and stubbornly defending their positions against your assaults, it is not that they do not want to get your point. Simply enough, your stakeholders see things in a different light, and probably, they cannot see through the curtains where your point of view lays; in the same way, as you could not see one of the two characters in the first figure, when I asked you to try.

Join people in their cognitive space

It is often useless attempting to persuade people, repeating the same line of thought many times.

Instead, try to explain your point starting from something your stakeholders know, from something they see. You have to step into their cognitive space, understand it and map it in yours. This is more or less how I explained to you how to visualize both images. I started from something you saw and mapped it into the other picture.

Managing discussions, meetings, stakeholders, and relationships with the presented approach, requires a good deal of time and effort. Nonetheless, it also explicitly states that you do care about other people's point of views.

Indulge me a little more, and please take another quick look at the image in Figure 1.

What have you seen this time?

Bias of the cognitive space

The chances are that now you have immediately identified the image you saw for second, the one that I mapped in your cognitive space. Why?

Because we tend to retain more easily concepts we have worked upon, than those we have spontaneously elaborated on a whim. The phenomenon you have just experienced explains why, in the long term, working in the cognitive space of the other people is a very effective approach.

Well...I am going to ask you a little more of your time.

Please, take a look at the images in the first figure and try to identify alternatively both the characters.

Get Skilled

The more you get used to identify the different characters in the first figure, the more you find it easy, and the more you are able to do it quickly.

In the same way, the more you get used in joining people in their cognitive space and mapping it in yours, the more you will be able to explain your point of view to other people and understand their.

Bacchus or two lovers kissing?

High society or a donkey?

A skull or two little girls with a puppy?

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

Stakeholders management - A human touch

In my last post I dealt with the stakeholder register, I described its importance in project management activities and offered some suggestions for its filling.

stakeholders identification processes are of the greatest importance for a project and so are stakeholders information gathering activities, though this is just the starting point for effective stakeholders management.

In the following of the post I will give just some tips (or I should say some crumbs)  to avoid that everything become too unbalanced towards the documentation part, casting a shadow on the human aspect of these processes.

It is not I and them but us

Usually many of your stakeholders belong to your professional network and in many cases, well, they are your professional network.

Therefore it is extremely important the protection of your relationships and an effective management of their expectations. 

There will come the time in which, as a project manager, you will need your stakeholders help, support  and contribution to deliver succesfully your project.

Try to build and mantain loyal relationships with them through sincerity, sense of belonging, trust, consistency of performance, … relationships that go far beyond reciprocal satisfaction.

Relationships based on reciprocal satisfaction are about what they can do for you, or what you can do for them, if you see it the other way round.

A relationship based on loyalty is about what you can build together.

I have found extremely inspiring about loyal relationships a speech given by James Kane that I attended to the last PMI North America Global congress and this book by Simon Sinek.

  

They are individuals

They are individuals not just entries in a dedicated register. Group them together according to some criterion is definitely useful and convenient for generic project management activities, but this is just a modelization of reality. 

They are not a group. They do not want to be a group. They want to be individuals and they deserve to be treated like that. They are men and women with their complexities, beliefs, needs and expectations.

So respect their individualities. There is not such a thing like one size fits all stakeholder management and communication.

They are not sheep to graze nor cows to milk

They are people that can add great value to your project and all you have to do is listen to them (well...maybe it is a little more difficult than that...but this is a good start). Help them to express their potential, help them to enrich your project with their contributions and work together to build something unique.

Manage expectations and manage requirements are not the same sport

Managing requirements is about incorporate some characteristics in project deliverables.

Managing expectations has a far more broader meaning. It is about deliver to stakeholders the benefits they expect through project deliverables. This obviously has a lot to do also with your stakeholders needs understanding, project insight and vision, as I pointed in this my old post. 

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

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.

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

Report

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.

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

If I had asked people what they wanted...they would have expressed a requirement

Henry Ford is supposed to have said once

“If I had asked people what they wanted, they would have said faster horses”.

It is not really important if he had said this sentence for true, as is not very important the context in which this sentence would have been said.

What really matters is that many project managers, from time to time,  feel like saying that about their stakeholders. Such a statement implies two things

• A lack of trust in the stakeholders' insight and vision of the project.
• A lack of trust in the stakeholders' capability to express solid requirements.

This attitude could potentially lead to grave consequences in the long run, like stakeholders disengagement and failure in managing stakeholders' expectations.

The funny thing is that many times it is true.

Stakeholders do have limited insight into the project and yes, sometimes, they are not able to express requirements efficiently.

This lack of clarity is because they look at particular aspects of the project and not to the project as a whole.

In fact, they rely on project managers for activities such as the gathering of requirements, the definition of the scope, integration...

It is a project manager duty to provide the right degree of expertise, insight, and vision on the project. It is a project manager obligation managing stakeholders expectations and distilling requirements from necessities.

As Michelangelo Buonarroti wrote

"Non ha l'ottimo artista alcun concetto 

ch'un marmo solo in sé non circoscriva

col suo soverchio, e solo a quello arriva

la man che ubbidisce all'intelletto."

That is to say that the statue lives inside the marble block; the artist just removes the excess.

The sentence “If I had asked people what they wanted, they would have said faster horses” is an expression of a necessity that hides an implicit requirement.
The requirement is the need for a faster and more reliable transport.

Understand the best way to satisfy this requirement, respectful of the project's constraints, is a part of our job.

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

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.

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