Based on the definitions in A Guide to the Project Management Body of Knowledge 7th Edition, we know that projects are temporary endeavors. There is an implication in Appendix X4, specifically in Table X4-1, that in a project view, teams are also temporary. I read this to imply that a team is formed for a project and must disband after the project. However, I see nothing outside of an appendix supporting this.
Is there anything in the standard that precludes a staffing model where you have stable teams, and the team moves from project to project as a whole entity? These projects may or may not be within a broader program or portfolio or for the same product - the decision to align a team with a higher-level construct would be an organizational decision. Saving Changes...
Program Manager, PPM&PMO Specialist.| Coppel, Mexico.Culiacán, Sinaloa, Mexico
Any modification to the team creates a new team, thus necessitating new stakeholders for each project. Consequently, expanding the team to include stakeholders would essentially create a new team for every project
...
1 reply by Thomas Owens
Dec 02, 2024 2:23 PM
Thomas Owens
...
I don't see how this answers the question.
I would agree that changing the team is a new team. I would also agree that each project would have its own set of stakeholders (which may or may not be the same as a different project, past or present).
But this doesn't address the underlying concern, whether anything precludes a project team from being a long-lived entity.
The only argument I can see is that a team could exist as a stable entity within the organization, but it is only a project team within the context of a project. Even if the people on the team do not change between Project A and Project B, the fact that they are working on a different project means that they are a different project team.
Any modification to the team creates a new team, thus necessitating new stakeholders for each project. Consequently, expanding the team to include stakeholders would essentially create a new team for every project
I don't see how this answers the question.
I would agree that changing the team is a new team. I would also agree that each project would have its own set of stakeholders (which may or may not be the same as a different project, past or present).
But this doesn't address the underlying concern, whether anything precludes a project team from being a long-lived entity.
The only argument I can see is that a team could exist as a stable entity within the organization, but it is only a project team within the context of a project. Even if the people on the team do not change between Project A and Project B, the fact that they are working on a different project means that they are a different project team. Saving Changes...
It's a matter of semantics. A project team has no meaning without the context of a project so the project team always disbands at the end of the project. If A (project team) is a subset of B (project) "A ⊂ B" and if B is deleted then all subsets of B are as well.
In functional based organizations, many projects are contained within existing teams managing their discrete function and once completed the project team disappears but the people are still part of the organization. Those people may also work multiple projects simultaneously, some fully contained within their organization and others across functional boundaries.
...
1 reply by Thomas Owens
Dec 02, 2024 3:55 PM
Thomas Owens
...
This makes a lot of sense.
This handles a lot of cases. Another case is if the same team of people is working on Project A and Project B - this is two project teams, even though they are the same people. When Project B ends (or is terminated), the project team associated with Project B ends. But you do have other cases where there is some overlap (but not a true subset) between two projects as well. So thinking about the project team as specifically the team associated with a project, regardless of other projects or outside organizational structures, has advantages.
It's a matter of semantics. A project team has no meaning without the context of a project so the project team always disbands at the end of the project. If A (project team) is a subset of B (project) "A ⊂ B" and if B is deleted then all subsets of B are as well.
In functional based organizations, many projects are contained within existing teams managing their discrete function and once completed the project team disappears but the people are still part of the organization. Those people may also work multiple projects simultaneously, some fully contained within their organization and others across functional boundaries.
This makes a lot of sense.
This handles a lot of cases. Another case is if the same team of people is working on Project A and Project B - this is two project teams, even though they are the same people. When Project B ends (or is terminated), the project team associated with Project B ends. But you do have other cases where there is some overlap (but not a true subset) between two projects as well. So thinking about the project team as specifically the team associated with a project, regardless of other projects or outside organizational structures, has advantages.
I'd agree with you - PMI is not discounting the concept of a long-lived team with work being brought to that team. Certainly, after their acquisition of Disciplined Agile in 2019, this is encouraged whenever possible to reduce the "waste" of standing up new teams.
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Your answer is LPM (Lean Portfolio Management). I hate calling things <something> Portfolio Management but it is what it is. When organizations of all types use this approach they are funding teams, they are not funding projects because the key is create solutions where solution = product + project. I am using this approach from long time ago and in my personal case it works and beyond that there are a lot of studies, including it govermenet organizations, where it works.
...
1 reply by Thomas Owens
Dec 02, 2024 5:37 PM
Thomas Owens
...
This is the direction I was thinking when I asked the question.
Just because you fund a product or program or project doesn't mean that you don't have stable teams. The way an organization allocates resources is different than the fact that the team doesn't outlive its container. Just because you fund a team to work on a project doesn't mean that the team disbands even through the project team disbands. It does depend on the skills of the team and the project, though.
I think that's the misconception. Even though it's true that a project team disbands at the end of the project or a program team disbands at the end of a program, it doesn't mean that the people on the team won't generally stick together for the next project or program and become that project or program team. It depends on the organization and the needs of that next endeavor.
Your answer is LPM (Lean Portfolio Management). I hate calling things <something> Portfolio Management but it is what it is. When organizations of all types use this approach they are funding teams, they are not funding projects because the key is create solutions where solution = product + project. I am using this approach from long time ago and in my personal case it works and beyond that there are a lot of studies, including it govermenet organizations, where it works.
This is the direction I was thinking when I asked the question.
Just because you fund a product or program or project doesn't mean that you don't have stable teams. The way an organization allocates resources is different than the fact that the team doesn't outlive its container. Just because you fund a team to work on a project doesn't mean that the team disbands even through the project team disbands. It does depend on the skills of the team and the project, though.
I think that's the misconception. Even though it's true that a project team disbands at the end of the project or a program team disbands at the end of a program, it doesn't mean that the people on the team won't generally stick together for the next project or program and become that project or program team. It depends on the organization and the needs of that next endeavor.
...
1 reply by Keith Novak
Dec 02, 2024 8:53 PM
Keith Novak
...
Yes, when an organization has many similar reasons for projects, they tend to involve many of the same specialty skills, thus the same people, and by keeping mostly consistent project teams, you bypass much of team building growing pains. There is little forming and storming required. You are very quickly norming.
A potential problem with that however is that groupthink can easily set in. New ideas tend to get summarily dismissed and old ones accepted because old ones served the team well in the past and most people are resistant to change. One vocal team member opposed to something will easily convince the whole team to follow suit. That is where a disruptive influence may be intentionally inserted into the mix. It could be the PM such as when introducing agile in a waterfall environment, or someone with different views on the product itself. That job takes thick skin because the disruptor is often ostracized socially much like the new kid in school.
This is the direction I was thinking when I asked the question.
Just because you fund a product or program or project doesn't mean that you don't have stable teams. The way an organization allocates resources is different than the fact that the team doesn't outlive its container. Just because you fund a team to work on a project doesn't mean that the team disbands even through the project team disbands. It does depend on the skills of the team and the project, though.
I think that's the misconception. Even though it's true that a project team disbands at the end of the project or a program team disbands at the end of a program, it doesn't mean that the people on the team won't generally stick together for the next project or program and become that project or program team. It depends on the organization and the needs of that next endeavor.
Yes, when an organization has many similar reasons for projects, they tend to involve many of the same specialty skills, thus the same people, and by keeping mostly consistent project teams, you bypass much of team building growing pains. There is little forming and storming required. You are very quickly norming.
A potential problem with that however is that groupthink can easily set in. New ideas tend to get summarily dismissed and old ones accepted because old ones served the team well in the past and most people are resistant to change. One vocal team member opposed to something will easily convince the whole team to follow suit. That is where a disruptive influence may be intentionally inserted into the mix. It could be the PM such as when introducing agile in a waterfall environment, or someone with different views on the product itself. That job takes thick skin because the disruptor is often ostracized socially much like the new kid in school. Saving Changes...
Project Manager| AWR Development (BD) Ltd. Cox's Bazer , Bangladesh
HI Thomas
The PMBOK Guide highlights that projects are temporary, but it doesn't specifically say that project teams have to be temporary too. Organizations have the option to create a staffing model with stable teams that can smoothly move between projects, as long as it fits their goals and operational requirements. This flexibility in how teams are structured can really work in their favor!
Golam
...
1 reply by Thomas Owens
Dec 03, 2024 6:15 AM
Thomas Owens
...
My question was sparked because one part of the PMBOK Guide says that project teams must be temporary - Table X4-1 in Appendix X4.
Based on the earlier discussion, a project team is temporary in that it will always end when the project ends because a project team only exists in the context of a project. A given group of people could be multiple project teams at once or become a new project team at any time. This separates the notion of a project team from the organization's staffing and resourcing models.
HI Thomas
The PMBOK Guide highlights that projects are temporary, but it doesn't specifically say that project teams have to be temporary too. Organizations have the option to create a staffing model with stable teams that can smoothly move between projects, as long as it fits their goals and operational requirements. This flexibility in how teams are structured can really work in their favor!
Golam
My question was sparked because one part of the PMBOK Guide says that project teams must be temporary - Table X4-1 in Appendix X4.
Based on the earlier discussion, a project team is temporary in that it will always end when the project ends because a project team only exists in the context of a project. A given group of people could be multiple project teams at once or become a new project team at any time. This separates the notion of a project team from the organization's staffing and resourcing models. Saving Changes...
Community Champion
