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 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.
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.
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.
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.
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...
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.
Way cool! Some extremely valid points! I appreciate you penning this post… Easy Project management software brings more flexibility and convenience for handling even multiple projects for the companies and with its help each project can have a central access to Gantt chart of tasks, metadata, references, resources, documents, forums, permission management, preferences and a comprehensive e-form solution. Keep on sharing…
ReplyDeleteit's really a good article about project management,.
ReplyDeletethanks for the share,
"cloud based data storage "
Hi, great article on project management clear explanation with the example of the restaurant . I like the points of law of diminishing returns. thank you for this its a great help to me.
ReplyDelete