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 - execution efficiency or process efficiency?

Mario is a cook.

He owned a small restaurant in Rome, near the Trastevere district. It was a very tiny place, where he could welcome less than 20 people at the same time. The menu was also minimal; two appetizers, three first courses and two main courses. Period. 
The kitchen was successfully managed by Mario, his wife Sandra and his son Enrico. Since the quality of the served food was fantastic, the restaurant was always packed with people.
At a certain point, Mario decided that it was time for him to take a giant leap. He decided to expand the restaurant’s turnover and moved his activity into a new place, where there was room for more than 80 people. In addition, he decided to enrich the menu, introducing six new appetizers, three new first courses and four new main courses. Obviously he intended to maintain a very high standard for the food’s quality. 
Since Mario was no fool, he expected to need more help in the kitchen and hired two new people, his nephews Rita and Francesco.
Very soon begun the problems. Managing 80 meals with 288 possible permutations is far more complex that managing 20 meals with 12 possible permutations. As a result, the kitchen collapsed. 
Mario hired two more people on the staff, but this gave no acceptable solution to the problem, on the contrary, it seemed to worsen it even more. The kitchen was small, and the paraphernalia limited, so each more cook gave less incremental help. In addition, each more cook added a cost in terms of organization and management. Even worse, lack of coordination, poor management, organization’s failure started to impact even on food’s quality.
This short story is purely fictional. Nonetheless, I think we can learn a lot from it.

The law of diminishing returns

There is a point where the addition of new resources to a project ceases to produce benefits. Even worse, beyond this point, indiscriminate and continuous addition of resources could create further inefficiencies. This consideration applies to people, material, machinery, funds...
Similarly at what happens in a small kitchen, adding more and more cooks, can lead to a situation where there are not enough activities, tools or even space for each one. Then you have two ways to proceed. You can split activities further to occupy all the resources at your disposal, or you can turn resources on different activities. 
Each solution brings inefficiencies. In addition, more resources mean greater costs, more complex management plans and more management overheads.If we consider resources as workers, we also have  to take into account personnel training, insertion costs and the time needed to make the new team perform like the old one.
The bottom line here is that if your processes fail, adding resources could not be an option. 

Obsessive replication of the first success's pattern 

A one-size-fits-all methodology does not exist in project management (and in many other human activities). 
Since each project is different, it is possible that processes and plans that worked well in the past could fail, if slavishly and uncritically applied, in future situations. It is not a wrong practice to derive management plans and processes, from those previously successfully used in similar projects. 
We have to take care to spot all the aspects in which the projects differ and in which they are similar; we have to respect and to leverage the differences between them. Mario wrongly thought that processes that could be used to successfully manage a kitchen with three cooks (the project’s team) and eight courses for twenty people (activities and complexity), could be applied, out from the box, to the management of a far more large team with far more complex activities. 
The bottom line is always to assess, react and adapt.

A solution is never infinitely scalable

This paragraph has something in common with the previous one. Indeed, in some respects, we could say that this paragraph is about one of the reason why you cannot indiscriminately reply patterns. 
A process can be considered scalable if it can be applied, unchanged and with the same proficiency, even if there are quantitative changes (more or fewer people, activities, funds...) in the scenario. If these changes are increments we talk about upwards scalability, if they are decrements we talk about  downwards scalability. If the process can keep the same efficiency just adding or subtracting resources, we talk about vertical scalability. This kind of scalability is typically limited by the law of diminishing returns. If the process can maintain the same efficiency by means of replication in several parallel instances, we talk about horizontal scalability. This kind of scalability is generally limited by managing overhead.
The bottom line is that scalability does have a cost and that any process can be scaled infinitely upwards or downwards, neither vertically nor horizontally. There is a point where scalability ends or where its cost far exceeds the benefits. In these cases, processes have to be revised. 

Join execution efficiency to process efficiency 

Since a solution is never infinitely scalable, it is mandatory to develop the skills necessary to achieve an excellent execution efficiency. 
However, since the law of diminishing returns, we must bear in mind that it is of the greatest importance also achieve  a high process efficiency.

Conclusions

Is it a smart approach, applying previously used processes to future projects? 
Yes, if these projects have, in their most sensible aspects, similarity with the projects for which these processes had been originally crafted. Even in this case we have to take our time to assess, react and adapt. 
We have also to pay attention that the processes we are applying, be scalable in the desired way and direction, to accommodate differences in projects’ sizes. Doing this keep in mind the law of diminishing returns, because the obvious solution of adding resources, may be highly counterproductive in a critical situation. 
Finally, we have to balance execution efficiency with process efficiency.

By the way, for all our North American friends, Mario has never served in his restaurant the famous Fettuccine Alfredo...if I have to say the truth...I have never seen them in any restaurant here in Italy...

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

Are your project objectives S.M.A.R.T. enough?

I love acronyms.

I have always considered acronyms as incredibly shrewd and useful tools, for communicating and for remembering complex concepts in a simple and effective way.

In this post i will focus on one acronym that I came across the first time while studying Prince2 and that, as often happens, I then met again several times in the following days, even if slightly modified.

The acronym is S.M.A.R.T. and, related to project objectives, stands for Specific, Measurable, Achievable, Realistic, and Time Bound.

Honestly, I have to say that there seems to be no universal agreement on the words whose initials make up this acronym, as you can see by following this link. However, the version presented here is the one that I find more congenial and useful to my needs.

Specific

How could you hit a target, if you do not know where the target is? Or worst, how could you hit it, if you do not even know what the target looks like? In the same way you cannot achieve a objective if you do not provide (or if you have not been provided with) a clear description of the objective itself.

It seems obvious, I think that everyone would agree with the previous statement...but please keep in mind that defining specific objectives for a project is not an easy task.

To state or analyze a clear and well crafted business case, considering all present and future developments, benefits and advantages, requires both great project insight and business vision. You could need the aid of a business analyst and, possibly, great support from your corporate management.

If you have been provided with project documentation, in the form of a charter or of a project brief, take your time to examine it carefully and request clarifications wherever necessary.

Never get tired to inquiring your project's documents because, you know, the devil is in the details.

I believe that not to specify clearly project objectives is not a smart (and obviously not a S.M.A.R.T.) shortcut but the highway to failure.

Measurable

All the objectives must be measurable. Period. Always. Period.

If you do not have measurable objectives, it will be impossible to determine if you have been successful or not. It will also be impossible to determine the degree to which the project has fulfilled its expectations.

Also as you might rationally decide to terminate or to continue the project, if you do not have precise targets to measure progress? How could you reassess  the business case? This could result in a massive expenditure of money without proper justification. Also, if you haven’t properly quantified your objectives, it is consequently impossible to determine their risk exposition and, as a consequence, it is impossible to determine the project’s risk exposition. No good. Believe me. 

The problem here is to find proper ways to measure objectives.

Even this one can be a daunting task, depending on the particular industry you are in.

It is easy to measure the number of defective pieces of equipment coming out from a production line, or the lifetime of a new electric bulb. It is more difficult when it comes to customer satisfaction, software quality, reputation improvement, products quality improvement...In these cases an indirect measure could do the job.

As an example you could measure the number of contacts of your customer service  and put it in relation with an improvement or a worsening of your products.

The bottom line is: everything can be measured, the problem is to identify suitable measurement units. It is a complex problem but is a problem that can be and must be solved.

Achievable

Some objectives just do not go well together. They seem to live in orthogonal dimensions.

Sometimes it seems that a complete scope, a fast time to market, a low budget and an high quality standards mix well...as oil and water.

So take care in having an achievable and consistent set of objectives. If it is not the case, try to reconcile reality with management's desires and expectations.

Never start a project that has not achievable objectives, pretending that everything is just fine and thinking ahead how to justify the unavoidable failure or below average performance.

Realistic

Everyone would like to be in charge of the next multi-billion dollars, thousands resources, hundred contracts project, with all the whistles and bells. Reality is, many times, different. 

The project manager’s duty is to reconcile budget, time, scope, quality and all the other constraints into a shared and satisfying vision, be he/she in charge of a mega project or working in small businesses. The duties of a project manager toward the sponsor and the stakeholders do not change with budget’s size. Again, he/she must reconcile reality with management desires and expectations and must resist the temptation to artificially raise the bar in order to magnify its own role.

Time Bound

Every project should have a starting date and an ending date. Every objective should be achieved in the defined timeframe. Benefits could be achieved later on but a time span have to be defined as well.

This is an important commitment for a project manager.

So there is no point in defining objectives that cannot be achieved in the project timeframe or in the expected time for benefits realization, once project products are released in the operation environment.

Otherwise, an attitude of this kind could frustrate team members, create distrust in corporate management and alienate stakeholders. 

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

Are your processes fair enough?

Let me play a little game with you, just to introduce the subject of this post.

I am a project manager and you are a member of the project team. 

I have put in place all sorts of management processes and I have bound team members bonuses and prizes to the outcomes of these processes.

This is one process that I put in place and that now you will have to apply.

Your quarterly bonus depends on the fact that I will consider reasonable and satisfying the outcome of the process.

Follow this process. You can use a piece of paper and a pen.

1. Choose a number between 1 and 9. write it on the piece of paper.
2. Double it.
3. Add 8 to the result obtained in point 2.
4. Divide by 2 the result obtained in point 3.
5. Subtract your original number from the result obtained in point 4 and write the result on the piece of paper. 
6. Convert the result from point 5 into a letter in the English alphabet (es A=1, B=2, C=3,...)
7. Choose a U.S.A. state whose name begin with the letter you have found.
8. Add 1 to the result obtained in point 5 and write the result on the piece of paper. 
9. Convert the result in point 7 to a letter with the same method you have used in point 6.
10. Choose the biggest animal you can think about whose name start with the letter you have found.

Now...well...I am very very very disappointed from your performance.

there are no elephants in Delaware...very unsatisfying... you can kiss goodbye your quarterly bonus.

Are you disappointed? I think you are. You have plenty of reason to be disappointed.
Many mistakes have been made in implementing this process, but we will focus on what I judge to be the worst four.

Give measurable targets

At the beginning of the post I wrote that I would have granted you a bonus if, and only if, I would had found “reasonable and satisfying the outcome of the process”.

So? What is this supposed to mean? Nothing.

If you put in place a project management process and you bind your team members bonuses and prizes to the outcome, be sure to give measurable objectives.

Otherwise every denied bonus will be seen as an arbitrary punishment and every granted bonus as an unjustified gift. Each case you will be experimenting a sudden collapse of trust among your team members.

Give team members a chance to influence the outcomes they are evaluated against to

You had no control on the output of the process that I put in place and that I forced you to follow.

Every input you would have given would have led you to the same result. So what is the point in binding your bonuses on that? 

Again, as in the previous point, every denied bonus will be seen as an arbitrary punishment and every granted bonus as an unjustified gift. You will be experimenting a steady collapse of trust in the team and you will grow harsh criticism about every step the management will take. Discontent will spread.

Always perform a sanity check of your processes

The process that I forced you to follow was corrupted (How could I possibly knew your answer otherwise...). Look at the equation you have implemented following my process

1. Chose a number between 1 and 9. write it on the piece of paper. Let’s say the number you chose is X and the result you obtained is Y.
2. Double it. Ok, now you have Y=2X.
3. Add 8 to the result obtained in point 2. Here we obtain Y=2X+8.
4. Divide by 2 the result obtained in point 3. Now Y=(2x+8)/2=X+4.
5. Subtract your original number from the result obtained in point 4 and write the result on the piece of paper. Y=X+4-X=4.
6. Convert the result from point 5 into a letter in the English alphabet (es A=1, B=2, C=3,...). The letter you got was D.
7. Choose a U.S.A. state whose name begin with the letter you have found. There is only 1 U.S.A. state whose name starts with D. Delaware.
8. Add 1 to the result obtained in point 5 and write the result on the piece of paper. The number you got was 5.
9. Convert the result from point 7 to a letter with the same method you have used in point 6. The letter you got was E.
10. Choose the biggest animal you can think about whose name start with the letter you have found. Elephant is a good choice.

If you put in place a project management process and you bind your team members bonuses and prizes to the outcome, be sure that your process is flawless.

Otherwise two things could happen

• Your team members will not follow your process, because they want achieve their bonuses and prizes and because your process outcomes go to detriment of the project.
• Your team members will follow your process and contextually will experience a lot of frustration. You are sure to have an high degree of disengagement...and probably a lot of elephants in Delaware.

Either cases lead to the same result.

The project will rapidly go out of control and disappointment will spread among all of your stakeholders.

Always check that your processes are fair

Make another little experiment. Buy a cookies box and tomorrow morning, as soon as you enter the office, gather three of your collegues and offer them some cookies. You will offer four cookies to two of them and you will say to the third one that he/she can take just one cookie.

Chances are that the third collegue will ask you why he/she can get just one cookie.

There is no point in asking, since cookies are yours and you do not owe nothing to your collegues. You can share your cookies if you want to and decide freely how many cookies offer to whoever you want but still, the third collegue will ask you about it, maybe laughing, but he/she will ask. Maybe even the other two collegues will enquiry you about your behavior. And you know why?

Beacuse deep inside they feel that your process is unfair. Even if they have been prized in this occasion, they know that they cannot trust your process. They know that they cannot trust you.

My point is to always check that your processes are fair.

People can stand almost every situation and deprivation, but just if they feel that the processes are fair.

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

Assumptions and data: never get tired to question them

Let me play a little game with you, just to introduce the subject of this post.

Solve this very easy riddle. 

“Hi, 

I am a very big mammal. 

I am an herbivorous.

I have a grey thick skin.

You can find me in Africa but I have cousins in Asia.

I have been (and I am still) hunted by humans because of something that grows near my mouth.

Who am I?

If you want to meet me follow the link.”

Are you surprised?

Did you expect to meet this other African friend?

Well...you are not totally wrong...or more precisely...you are right...too.

From the data at your disposal both the answers were right. Both these animals are big herbivorous mammals with a grey thick skin. Both of them are present in Asia and have been hunted almost to extinction because of something that grows on their muzzle...and yes...nose and mouth are quite near.

Almost everyone indicates the elephant as a solution for this riddle, probably because elephants are more ubiquitous than rhinos on television, cartoons, books, tales...

What your brain does

The fact is that you have been provided with true but incomplete data and your brain automatically tried to fill the gaps in the best way it could. It tried to interpolate data where informations were lacking.

This capability is something wonderful and amazing at the same time. Your brain, starting from some provided data and past stored knowledge, suggests you answers when you have to take decisions. This same capability is what comes at your help when you have to make an educated guess about some event in the future.

I value this as one of the most important characteristics of human beings.

Take it easy

Please, do not have fear, in this specific case is not your brain that have deceived you...but the other way round...you probably have not provided him with enough time to give a well crafted answer to the riddle I proposed you.

Probably if you had waited a little, if you had just taken your time before trying to give the answer it would have come to your mind that the riddle would have been satisfied by at least two answers. The problem was that everything seemed so perfect, the data seemed so accurate, so precise that you jumped directly to your conclusion. 

This happens in day to day life and in project management too, whenever we have to deal with data and/or assumptions to take decisions.

Sometimes we trust too much the data we have been provided with or the assumptions we have accepted as true, especially when data seem so well crafted and our first answers seem to fit so magically...in this cases sometime we are driven to rush headlong to conclusions.

What we have to deal with

In Figure1 we can see a pictographic representation of a two dimensional data  space, where data and assumptions are placed using their degree of completeness and reliability. Above the yellow line we have data and assumptions more reliable than complete. This is the same situation we have faced with the riddle.

Below the yellow line we can find data and assumptions more complete than reliable.
Both situations are critical.

Figure1.

In the first situation efforts have to be made to collect more data and to refrain from giving the answer too quickly. Take your time. If it is too good to be true...probably it is not true. So try to collect fresh informations and evaluate alternatives to your decision.

In the second one efforts have to be made to verify and validate data and assumptions, discarding corrupted ones. The problem is...how do we know that our data are not reliable or our assumptions are fault? 

Well...the only answer I can offer is to never get tired to analyze, check, question and validate.

Always perform data and assumptions sanity checks, base your analysis on literature, consult with the team, consult with the stakeholders, consult with other project managers and with your project management office... Check lessons learned related to other similar projects if you can access them.

...So

Maintain these behaviors for all the project life. Never get tired to evaluate alternatives and to question and check your data and/or assumptions...or you run the risk to mistake an elephant with a rhino...or even worse...an assumption with a million dollars gamble. 

Thank you for reading.

Bye.

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.

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

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

Project management resources from Tasmania

Tasmania is an archipelago comprising more than 300 islands situated about 250 Km south of the Australian continent, from which is separated by the Bass Strait. The main island is named Tasmania after Dutch explorer Abel Tasman, who reported its existence on 1642. 

It is a sovereign state and counts nowadays more or less half a million inhabitants.

These are all well known facts but there is something peculiar that maybe not everyone knows.

Tasmanian government on its own created a project management framework named Tasmanian Government Project Management Framework, comprised of the Tasmanian Government Project Management Guidelines and many supporting resources. I have come to know this attending an amazing presentation given by Sean Whitaker at the last Project Management Institute Global Congress in Vancouver.

This framework has been realized to be a guideline for every Tasmanian government agency and it is freely consultable from here, the official Tasmanian government web site.

Resources that can be found are

• Mailing list. It was meant to be a way for sharing project management ideas between Tasmanian government employees. However to facilitate collaborations between public and private sectors subscription is not subjected to any restriction.
• Framework documentation and generic project management tips.
• Templates for generic project management activities related documents. 
• Checklists to assess project characteristics or the degree best practices are being implemented.

All materials is organized in sections

Getting started in project management
This section provides informations and resources on basic project management topics, to help everyone get started in basic project management activities.

Project life
This section provides informations and resources to help managing projects, organized in a kind of project life cycle. We can find here tutorials and templates to organize the project, create Gantt charts, create WBS, report the project status,...

Project management guidelines
This section describes how to manage a project following the Tasmanian government framework, identifing and explaining all the included key processes. This document is realeased under the creativecommons Attribution 3.0 Australia license.

Supporting resources
This section contains resources to help project managers to set up and manage projects like fact sheets, templates toolkits...

Project Management advisory committee
This section contains the meaning and the pourpose of the tasmanian government project management advisort committee (PMAC for short).

Further information

This section mainly contains examples and presentations.

As I said all the material is freely consultable from the internet and I have proposed it in this post as a source of information and for self-learning pourpose. If anyone is interested in downloading part of the material here presented and using it to manage his/her own project, I recommend to ask for permission following one of the many information links provided by the Tasmanian government on its official web site.

These resources could be very useful for someone who is taking his/her first steps in the project management world, as it essentially covers basic project management principles and activities.
Nonetheless I think that even an experienced project manager could get some benefit. 

Who knows where the next good idea or tip will come from ?

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

Project management is the art of the possible

"Politics is the art of the possible" is said to have declared Otto Von Bismarck in 1863 to an interviewer from the St. Petersburgische Zeitung.

I am nor an aphorisms fan neither a Bismarck admirer but in its apparent triviality this sentence hide two big truths.

• A pragmatic and wise politician distinguish between realities and desires, between opportunities and treaths, between possibilities and obligations. He or She has to know the environment in which  he or she operates.
• Planning and negotiations, if properly conducted under a correct knowledge and interpretation of the previous environmental factors, can always lead to success. Provided objectives are realistic.

In this respect I state that (also) project management is the art of the possible. 

A good project manager should be able tell a viable budget or schedule from what are just hopes. He or She should be able to tell reality from management desires and hopes and eventually reconcile the differences. Obviously he or she should absolutely not commit himself  or herself to what is a beyond belief schedule (or budget, scope, quality plan, ...). I think that in many cases, especially if a project manager has not been involved in the project chartering process, this could be one of the most tricky parts of project management. 

Opportunities and treaths are what we could call risks and they should be treated through appropriate project management techniques. They should be identified, evaluated, documented and periodically revised. Plans should be put in place to address them in case they happens, to mitigate or enhance their impact on the project.

Every wise project manager knows that penetrating and understanding the environment in which the project evolve is a basic step toward a successfull completion. Marketplace conditions, industry standards, competitors, processes, tools, management attitude, Sponsor support, budget constraints, knowledge bases,... are all factors that can help or  hamper the project manager's (and team's) efforts and options. So all this factors, all this possibilities and obligations has to be continuously kept in mind and mastered. 

Under these premises the project manager operates and leads the team, implementing valuable processes and applying techniques suitable for planning, negotiating, monitoring project status and controlling project flow.

Said that, I strongly believe that if there is even a remote possibility to conclude a project on time, on budget and with a certain degree of quality, proper project management combined with an insight into environmental factors and process assets can significantly exploit the possibilities of success.

Obviously no project manager can do magic. Some conditions (good chartering, strong business case, management commitment...) has to be put in place before project start. A good project manager knows how to make use of everything is around him but remember, project management is the art of the possible.

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