Diego EscobarSr. Project Manager - CALA Region| TCRP S.A.Buenos Aires, Capital Federal, Argentina
Projects are unique developments and there is not a unique way of managing a project. Projects that a company runs can be of very different sizes and complexities, and this leads to that not everyone should and can be handled in the same way, with the same processes.
The project plans are the first and more important communication tool for the team's work and is a document that is in constant evolution, as more information becomes available. Therefore, is fundamental that it contains only what is required for the execution and control of a project.
PMBOK processes are intended to be fully comprehensive, i.e. that it is not any practice without treatment, but we know, and same PMBOK says it, not all projects require the same degree of thoroughness, with which the project team must determine to what extent organizes a project following the necessary processes, according to the best practices promoted by the PMI.
One of the key tasks for a project manager is then to determine to what extent it is advisable (because there are no truths or absolute results) deploy the necessary procedures so that the organization of the project have a fair measure of benefits and costs of that organization. Remember that when we speak of organization, speak of knowledge areas, resources, processes, systems, documentation, etc.
This activity to determine the Organization of the project, is perhaps the most integrative for the project manager, because first of all, it must be placed in the environment where is developed, basically, which organization, with what culture and what assets it has.
Depending on these factors, we should establish the minimum requirements that must have a project plan and should be replicable in all cases, and can thus become a "template" of the project management plan.
Other subsidiary plans and processes, should be able to be suitable to the particular characteristics of each project within an organization.
As well as the organization assets are important (templates, processes, etc.), more important is the criteria with which the assets are chosen, so the choice result in processes according to the human and monetary resources that can be allocated to that organization's project. I.e., find an organizational structure of the project commensurate according to the dimensions of its purpose.
This activity of determine the organizational structure according to the project, (as far as I know) is not covered by any framework of best practices, but perhaps is possible get to basic recommendations depending on the features and the purpose of the project, that allow us estimate (unless intuitively) that cost / benefit relationship of the implementation of a determined plan.
If we look at planning processes diagram in PMBOK, we can not only appreciate the complexity that can be to develop a project with all processes plan, but even the complexity that can entail making the right choices from the processes that we need. Let us remember that there are dozens of sub-processes that someone will have to manage within each process. Clearly, if we have a project of such a scale that deserves the rigorous follow-up of ALL the processes of the PMBOK, is not the project manager who should be managing directly all of them. For example, there should be a responsible for the administration of the Risk Management Plan, who periodically report to the project manager on exposure of the project risks, along with "owners" for certain risks, etc.
Because this is not the usual case of many projects, normally we are facing intermediate levels , where precisely the team should select its methodology. Going back to risks, not in all the projects is performed a quantitative analysis of those risks and simply there is in a qualitative analysis and some plans for contingency.
It is precisely here, where this analysis work begins, in which, according to certain characteristics of the projects, we can arrive to plans according to project and outcome needs, in a balanced cost-benefit ratio.
The question now is: would it be possible to arrive to some kind of standard process or workflow based in project information that help us arrive to such project plan?
I appreciate every comment and suggestion and any help to continue with this work. Saving Changes...
I have some thoughts, but want to make sure I understand the question. Are you asking about a standard process for scaling projects?
...
1 reply by Diego Escobar
Oct 21, 2016 3:01 PM
Diego Escobar
...
Aaron, yes, you get to the point, but I want to arrive to some kind of a standard (I don't know if something like this already exists). By instance, what questions must we make and the what are the correct answers to get the most cost/effective project processes, team, paperwork, etc.
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
That is part of the tailoring done for a project, during the planning stage. At the end, you should have processes and tools that will work for your project.
...
1 reply by Diego Escobar
Oct 21, 2016 2:55 PM
Diego Escobar
...
Stephane, totally agree with you. What I am looking for, is to create some standard guidance specifically for this planning task, in order to arrive to the processes and tools that best fit a project, based on project preliminar information, like number of stakeholders, complexity of requirements, budget of the project and the product, etc.
Saving Changes...
Diego EscobarSr. Project Manager - CALA Region| TCRP S.A.Buenos Aires, Capital Federal, Argentina
Oct 21, 2016 11:54 AM
Replying to Stéphane Parent
...
That is part of the tailoring done for a project, during the planning stage. At the end, you should have processes and tools that will work for your project.
Stephane, totally agree with you. What I am looking for, is to create some standard guidance specifically for this planning task, in order to arrive to the processes and tools that best fit a project, based on project preliminar information, like number of stakeholders, complexity of requirements, budget of the project and the product, etc.
...
1 reply by Stéphane Parent
Oct 21, 2016 3:07 PM
Stéphane Parent
...
One of my previous employer would have a PMO representative walk through all the organizational process assets relevant to managing a project. We would walk through the list and decide what was needed. If something was not needed, I had to provide a justification that was captured. We would then talk about tailoring some of the organizational process assets. The status was, again, captured.
Saving Changes...
Diego EscobarSr. Project Manager - CALA Region| TCRP S.A.Buenos Aires, Capital Federal, Argentina
Oct 21, 2016 10:53 AM
Replying to Aaron Porter
...
I have some thoughts, but want to make sure I understand the question. Are you asking about a standard process for scaling projects?
Aaron, yes, you get to the point, but I want to arrive to some kind of a standard (I don't know if something like this already exists). By instance, what questions must we make and the what are the correct answers to get the most cost/effective project processes, team, paperwork, etc.
...
1 reply by Aaron Porter
Oct 21, 2016 5:58 PM
Aaron Porter
...
A company I used to work for went through three attempts at a PMO before they found the right mix. In the second attempt, they tried something similar to what you are describing. They developed a full methodology to make sure everything was covered. When they came to our office to share it with us, they had to print it on a plotter; it was about 15 feet wide and was not large print.
One of their selling points was that you didn’t have to follow the full methodology. During initiation, you provided them with the project scope, and other details, and they returned a scaled down methodology that identified your phases, the processes you should use, artifacts that should be delivered and when they should be delivered.
The business was not ready for this. It did not last long.
The company I currently work for has taken the opposite approach. They have identified the minimum that should be part of a project. It fits on one 8½” x 11” piece of paper, with room to spare. You can do more than that, and on larger projects you should, but the point is to not create so much overhead that it impedes the actual work of the project. My Director has contributed to the last few versions of the PMBOK. He understands it, and still chooses a minimalist approach.
To be fair, I do not work in a highly regulated industry. In a highly regulated industry, you would probably need something more rigorous. There is a point, however, when the value added by such an approach begins to diminish. Regardless of whether or not you take a rigorous approach, identify those things that are mandatory due to compliance regulations or laws, and make them required. After that, find the right balance between overhead and work that furthers the goals of the project. Be careful with Best Practices (http://blogs.tedneward.com/post/there-is-n...ontext-matters/ ). Let your project teams have the ability to decide which practices fit best given the context of the problem(s) they are trying to solve. Give them options, give them a minimum, give them recommendations with reasons for the recommendations, and trust them. If you can’t trust them, your problems will not be solved by a rigorous approach.
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Oct 21, 2016 2:55 PM
Replying to Diego Escobar
...
Stephane, totally agree with you. What I am looking for, is to create some standard guidance specifically for this planning task, in order to arrive to the processes and tools that best fit a project, based on project preliminar information, like number of stakeholders, complexity of requirements, budget of the project and the product, etc.
One of my previous employer would have a PMO representative walk through all the organizational process assets relevant to managing a project. We would walk through the list and decide what was needed. If something was not needed, I had to provide a justification that was captured. We would then talk about tailoring some of the organizational process assets. The status was, again, captured. Saving Changes...
Aaron, yes, you get to the point, but I want to arrive to some kind of a standard (I don't know if something like this already exists). By instance, what questions must we make and the what are the correct answers to get the most cost/effective project processes, team, paperwork, etc.
A company I used to work for went through three attempts at a PMO before they found the right mix. In the second attempt, they tried something similar to what you are describing. They developed a full methodology to make sure everything was covered. When they came to our office to share it with us, they had to print it on a plotter; it was about 15 feet wide and was not large print.
One of their selling points was that you didn’t have to follow the full methodology. During initiation, you provided them with the project scope, and other details, and they returned a scaled down methodology that identified your phases, the processes you should use, artifacts that should be delivered and when they should be delivered.
The business was not ready for this. It did not last long.
The company I currently work for has taken the opposite approach. They have identified the minimum that should be part of a project. It fits on one 8½” x 11” piece of paper, with room to spare. You can do more than that, and on larger projects you should, but the point is to not create so much overhead that it impedes the actual work of the project. My Director has contributed to the last few versions of the PMBOK. He understands it, and still chooses a minimalist approach.
To be fair, I do not work in a highly regulated industry. In a highly regulated industry, you would probably need something more rigorous. There is a point, however, when the value added by such an approach begins to diminish. Regardless of whether or not you take a rigorous approach, identify those things that are mandatory due to compliance regulations or laws, and make them required. After that, find the right balance between overhead and work that furthers the goals of the project. Be careful with Best Practices (http://blogs.tedneward.com/post/there-is-n...ontext-matters/ ). Let your project teams have the ability to decide which practices fit best given the context of the problem(s) they are trying to solve. Give them options, give them a minimum, give them recommendations with reasons for the recommendations, and trust them. If you can’t trust them, your problems will not be solved by a rigorous approach.
...
1 reply by Diego Escobar
Oct 24, 2016 9:19 AM
Diego Escobar
...
Aaron, thanks again for your comments. I am not looking for best practices, but for recommendations. And of course a minimal of basic mandatory processes based in the context. But giving recommendations, based on the business and previous experience, may be very helpful. Recommendations rather than processes because no project is identical to another. And of course, as you say, trust in your team is a fundamental condition to have success.
Saving Changes...
Diego EscobarSr. Project Manager - CALA Region| TCRP S.A.Buenos Aires, Capital Federal, Argentina
Oct 21, 2016 5:58 PM
Replying to Aaron Porter
...
A company I used to work for went through three attempts at a PMO before they found the right mix. In the second attempt, they tried something similar to what you are describing. They developed a full methodology to make sure everything was covered. When they came to our office to share it with us, they had to print it on a plotter; it was about 15 feet wide and was not large print.
One of their selling points was that you didn’t have to follow the full methodology. During initiation, you provided them with the project scope, and other details, and they returned a scaled down methodology that identified your phases, the processes you should use, artifacts that should be delivered and when they should be delivered.
The business was not ready for this. It did not last long.
The company I currently work for has taken the opposite approach. They have identified the minimum that should be part of a project. It fits on one 8½” x 11” piece of paper, with room to spare. You can do more than that, and on larger projects you should, but the point is to not create so much overhead that it impedes the actual work of the project. My Director has contributed to the last few versions of the PMBOK. He understands it, and still chooses a minimalist approach.
To be fair, I do not work in a highly regulated industry. In a highly regulated industry, you would probably need something more rigorous. There is a point, however, when the value added by such an approach begins to diminish. Regardless of whether or not you take a rigorous approach, identify those things that are mandatory due to compliance regulations or laws, and make them required. After that, find the right balance between overhead and work that furthers the goals of the project. Be careful with Best Practices (http://blogs.tedneward.com/post/there-is-n...ontext-matters/ ). Let your project teams have the ability to decide which practices fit best given the context of the problem(s) they are trying to solve. Give them options, give them a minimum, give them recommendations with reasons for the recommendations, and trust them. If you can’t trust them, your problems will not be solved by a rigorous approach.
Aaron, thanks again for your comments. I am not looking for best practices, but for recommendations. And of course a minimal of basic mandatory processes based in the context. But giving recommendations, based on the business and previous experience, may be very helpful. Recommendations rather than processes because no project is identical to another. And of course, as you say, trust in your team is a fundamental condition to have success. Saving Changes...
Community Champion
