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.

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.