Acceptance criteria. A real life example.

Once, while travelling for business, I spent a couple of days in one of the most famous Italian art city. My staying was limited to a single night; anyhow my company booked me a 4 stars hotel. I knew that hotel classification in Italy goes to 1 to 5 stars. Therefore, I was more than pleased with the accommodation.

When I arrived at the hotel, I was a little bit puzzled. I genuinely thought to have entered through the wrong door. The hall was disordered and gloomy, crowded with horrible knick-knacks and decorated with cheap paintings. The walls would have greatly benefited from a new coat of paint. Many couches, scattered around with no evident purpose, impeded the way toward the hotel’s bar, who, in turn, seemed to have run out of every kind of international drink.

The elevator would have been more at its place in a warehouse than in a high standard hotel. My room was a mix of heterogeneous old cheap furniture, and there were no tents on the window. The television was a very old and economic model of an unknown brand. The bathroom was small, without windows and enlightened by an undersized fluorescent lamp. There was a problem with the shower's hot water tap, and the sink drain was not working very well. The room was very clean, I have to admit it, But I consider this a prerogative more than a feature.

Obviously, my company had no fault, since they have based the hotel's choice on the high rating. 

I had to stay for just one night, and my schedule was very tight, so there was no point in searching another accommodation. Besides I can adapt myself to far worst situations than that.

Still, once at home, I remained with the curiosity to understand how such a terrible hotel could have been rated 4 stars out of 5.

So I searched for and eventually found on the internet the last Italian national regulation in matter of hotels rating. I read it…and finally understood. 

I won’t report the entire normative; I will just give some examples of characteristics that a room of a 4 stars hotel must possess in Italy.

Double Room

• Surface of at least 15 squared meters.
• Private bathroom (surface at least 4 square meters).
• 1 double Bed, 2 bedside tables, 2 chairs, 1 small table, 1 armchair, 1 wardrobe, 1 mirror, 1 wastepaper basket, 2 bedside lamps, 1 stool.
• Satellite television.
• Phone and internet connection.
• Safe.
• Mini bar.
• …

As I have previously reported, these are just a few excerpts from the normative, but I think that you will have got my point by now. 

We have a list of requirements…but how about their acceptance criteria and quality constraints?

We have prescriptions about the rooms' size and the number and the kind of necessary furniture pieces...but nothing about their quality, their age, their aspect.

There must be 2 chairs in the room, and they can be different. One of them could even be a plastic garden chair, for what concerns the normative.

The requirement about the television could be equally satisfied by a plasma monitor 65 inches wide or by an old 13 inches CRT. It is not even mandatory that television is equal in all rooms.

The list could continue.

I understand clearly now that the hotel in which I have been is, without any doubt, a 4 stars hotel. 

The lesson I learnt on that occasion is that quality is the essence of a project and that requirements and deliverables without quality and acceptance criteria, are almost useless and deceptive. More precisely, a lack of care in registering quality and acceptance criteria for each requirement or deliverable, could seriously impede the project execution, raising an abnormal quantity of quality issues. This situation will inevitably have a huge impact on the project constraints and stakeholders satisfaction.

Please take a look at Figure 3.

Figure 3.

On the horizontal axis, a qualitative representation of the delivered quality can be found, while on the vertical axis there is a qualitative representation of the expected quality. 

The violet line is the locus of point for which the delivered quality is equal to the expected one. 

Under the violet line, there is what I call the “waste area”, a zone where the delivered quality exceeds, without purpose, the quality expected by the project’s stakeholders. A project manager, who get caught in the “waste area”, is probably wasting resources that could be saved or used more profitably elsewhere. A long permanence in this area could lead to constraints issues.

Above the violet line, there is what I call the “disappointment area”, a zone where the delivered quality is below the quality expected by the project’s stakeholders. A long permanence in this area could lead to rework, quality issues and, more generally, to problem in getting along with the project’s stakeholders.

In both cases, the implications and repercussions of a project manager’s deviation from the violet line are obviously proportional to the deviance's magnitude.

Inside the dotted rectangle, there is what I call the “safe area”, that is the locus of point for whom the delivered and expected quality, although not alike, can be considered satisfactory from all the project’s stakeholders. This area is generated by registering quality and acceptance criteria for each requirement and/or deliverable. It is a zone where the project manager can safely exchange quality with satisfaction, causing no harm. Understanding clearly the “safe area” position and extension can prevent a lot of problems and incomprehension or, in the worst cases, it can help the project manager in foreseeing them and in dealing with them.

Please, note that if criteria have not been registered, the “safe area” still exists, only that in this case there is no accordance about its extension and its position in the graph by all the project’s stakeholders.

A project manager must, of course, pay close attention to the fact that the acceptance and quality criteria be quantitative and measurable. Otherwise, they could be useless and deceptive too.  

So, every time you collect or express a requirement for a project, please be careful. Pay great attention to the quality of your solutions.

Otherwise, you could end up delivering an old 13 inches CRT instead of the new plasma screen expected by your stakeholders, or a Luigi XVI sofa where a plastic garden chair would have done the job.

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

Milestones - Advice for beginners

Please, take a moment to look this very short video, just to introduce the topic of this post.
A project manager reminds a project's supplier the approaching of a milestone, that heavily depends from a work package assigned to the supplier’s team.
Probably you will have noticed by now what these people are doing. They are trying to enforce a milestone that had been set some weeks before. Just that they are not enforcing the milestone that they are thinking about. They are not enforcing the milestone “This year, at the middle of July”, whatever that means, “some work packages will be completed, including WP 121-A”. The milestone they are enforcing is "This year, in July, there will be big troubles".
Let alone the fact that months are not a unit of measure, since they have different lengths, and that the same month contains a different number of working days from one year to the other.
The real problem is that “The half of July” has not a shared meaning at all.

Should it be the 15th or the 16th, since July has 31 days? Should it be somewhere in the week that contains the 15th (or the 16th), since the indetermination of the milestone seems to call an equal indetermination? Should it be the tenth working day of July, since normally we have twenty working days in a month?
This sort of things leads inevitably to problems. It would not be nice gather the sponsor and the main stakeholders in a room one month in advance, just to discover two days before that the milestone will be inevitably missed.
And this is just when all the parts involved are negotiating in good faith. If someone is trying to use this carelessness fraudulently to get some advantage, like the case in our short introductory video, there will be even bigger troubles.
Lucky enough, this is a kind of mistake that the greatest part of project managers would not make...but it can happen.
Especially if you are managing a small project, using just internal resources with whom you feel you have a special relationship, maybe a friendship, and apparently documentation is not a big concern for anyone.
The bottom line is to be extremely precise in setting milestones. Always. No matter the project complexity and size, no matter if it is a project with just four team members and one of them is your brother.

Milestones are just moments in time and have no duration,  as a consequence they can be set with an extreme precision, a clock's precision. And they should. 15th of July is not a moment, is a time span, it has a duration and this could be confusing. When will your deliverables be ready ? In the morning, in time for the 4pm o’clock meeting with the sponsor or in the evening, just before everyone leaves the office and they are pretty much useless till the day after?
Set your milestones specifying calendar date and time in hours and minutes. This way everyone knows exactly what will be accomplished and when.
Otherwise…look at this other very short video to see with your eyes what the worst consequences could be…

Bye.

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.

Output, Outcome and Benefit - Managing today to shape the future

One of the most interesting and fascinating themes in Prince2 project management approach is, for what I am concerned, the business case one.

I find extremely interesting the constant focus on the project's business case and the continued assessment of the project justification, viability, and sustainability.

Also, I have been so impressed by the distinction between Output, Outcome, and Benefit.

Figure 1.

Output Each specialist product that the project has to deliver, be it tangible or intangible. Outputs are commonly delivered after the project’s closure and sometimes even during the project’s life.

Outcome Results of the changes derived from the use of the project's specialist outputs by the users. Outcomes typically start to be achieved after the handover of the project's specialist products to users.

Benefit Measurable improvement resulting from an Outcome. If the outcome is perceived as a disadvantage, we are dealing with what is called a dis-benefit. Benefits generally start to be achieved after the Outcomes and (should) continue to be achieved for a time span planned in advance. Prince2 states the establishment of a specific plan that describes the methods and times to verify the achievement of the expected benefits.

In Figure 2 we can see a quantitative representation of the relationship between these three ideas. Obviously, the exact Outcomes/Benefits realization times heavily depend on the project’s characteristics and peculiarity. 

Figure 2.

Let’s make a simple example to better clarify this view.

The Buymybooks Limited is a small company that sells books via the internet. Orders are collected by means of their internet site but after the initial collecting phase, orders are printed and processed manually. Also, Buymybooks Limited does not have a software to manage its books warehouse.

Their sell and delivery processes are highly inefficient, resulting in delivery errors, high costs, high customers turnover, and progressive reduction in the market share.

To face this situation, the board of director has decided to introduce a management software system to manage the sale and delivery processes.

Output of the project will be an integrated software management system (orders and warehouse management). 

Outcome of the project will be an improvement of Buymybooks Limited sell and delivery processes efficiency.

Benefits of the project will be delivery errors reduction, smaller costs, higher profits and greater customers' fidelity.

So we can agree that there is need to pay a great deal of attention not only to the execution phase of a project but also to the design, support and closure phases. Furthermore, it is of utmost importance check the actual realization of benefits after the project closure. This action should be performed by program or corporate management as prescribed in the project’s documentation. 

As a consequence, I would advise to

1) Have a series of compatible and well-crafted benefits

This seems obvious, but it can be sometimes tricky. I have covered the topic in one old post. It has been conceived for project objectives, but it is well suited for project benefits too.

2) Do not just focus on the outputs delivery

Sometimes, is easy to focus just on output delivery and lose contact with project’s outcomes and benefits. It could happen if outputs are the only substantial point of contacts between the project and the team members (that sometimes ignore the big picture), or between the project and the external stakeholders. 

Also, it is not uncommon to rely just on outputs delivery to measure project’s completion or success.

3) Choose the best possible approach to maximize benefits

Since a significant part of the project’s value will be realized after project’s closure, take care, during project planning, in choosing the best possible project approach to maximize the expected benefits and not just the outputs production. 

In the same way, while drafting the business case, do not take into account just the specialist products realization and delivery costs. Keep an eye also on handover, maintenance and operational costs. 

Manage and execute the project thinking also to the desired outcomes and benefits, trying to increase the probability of success and to maximize their impact on business as usual. 

4) Close a project if it has been proved to be no more justified, viable and sustainable

A project is a mean to reach an objective and not an objective in itself. Stop investing in a project if it is not longer worth it, is not a failure. Honor to the project manager who conscientiously proposes an early closure of its project, out of respect for the corporate vision.

Keep on throwing money out of the window. That surely is a failure.

To keep track of some of this aspects, I suggest the use of two very simple tools.

benefits/benefits matrix (Useful for points 1 and 4)

The first one is a matrix on which all project benefits are listed in columns and rows, sorted by descending importance, from left to right and from top to bottom. Each benefit's importance is recorded near the benefit's code. You can find an example of the benefits/benefits matrix in Figure 3.

At the intersection of each row and column of the matrix, there is a symbol that explains the benefit's relationships. 

Figure 3.

The “+” sign represents a high degree of correlation between two benefits' viability. This bond leads to risky situations because there is a high probability to realize both the benefits (opportunity) or to miss them both (threat). 

The “-” sign accounts for a low consistency between two benefits. This bond leads to risky situations because the realization of one of the two benefit could jeopardize the achievability of the other one.
In the example depicted in Figure 3, the achievability of benefits B2 and B3 is correlated. Benefits B1 and B4 are not consistent, but the real problem is that benefits B2 and B4 are not consistent too and, as a consequence, also benefit B3 is jeopardized. So benefit B4 jeopardizes benefits B2 and B3, that are the most significant benefits of our project.

Especially if one or both the benefits are assessed as paramount, strong “+” or “-” relationships have to be dealt with the greatest attention by the project manager. 

if too much “+” and/or “-” relationships appear in the benefits/benefits matrix, it could be wiser TO conduct an additional analysis of the project's expected benefits and to reassess the project’s riskiness. 

If two benefits do not have specific relationships, the intersection between their columns and lines is left empty. Obviously, the matrix is symmetric by construction and the slashes on the main diagonal are inserted just for the sake of clarity.

Other symbols could be added to account for different relationships, even if I advise to keep things as simple as possible.

Even in this very simple form, this tool could help in identifying dangerous (-) or risky situations (+), and contribute to the definition of the project's objectives.

products/benefits matrix (Useful for points 2 and 3)

The second tool I want to present is a matrix on which all project products (outputs) are listed in rows and all project benefits are listed in columns. Benefits are sorted by descending importance from left to right. Each benefit’s importance is recorded near the benefit's code. You can find an example of the products/benefits matrix in Figure 4.

Figure 4.

Each intersection between a row (product) and a column (benefit) contains project's outcome's codes, and represents through which outcome a single product helps to achieve a benefit. The color code states the degree of importance of the product to the expected benefit's realization (e.g., red could mean high, orange average, and yellow low).

We can see, reading the matrix by columns, which product helps to achieve a benefit, and to which degree each product is necessary to this end.

In this way, we can maintain a constant focus not only on project’s outputs but also on project’s benefits, through project’s outcomes.

If we are forced to drop out a product, we can immediately see which benefits are at stake, their importance for the project and how much they are at risk. It is a simple way to depict the effect of a project scope modification on the project benefits.

In the same way, if we decide to sacrifice a benefit, we can immediately evaluate if there should also be a project’s scope modification.

If you feel like to read some suggestion on how to assign importance values to project benefits, please refer to this post. It has been conceived to suggest how to assign qualitative values of impact and probability to project risks, but I think that the content is perfectly adaptable to the current problem.

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

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.