September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
I'll avoid referencing "best practices" as those don't exist. However, where I feel more standards could be developed is around:
1. Tailoring guidance based on project contexts. The DA toolkit addresses that but isn't a "standard".
2. People-related challenges - for example, presenting bad news to a customer, dealing with unresponsive stakeholders and so on.
3. Dealing with complexity. Models such as Cynefin are there, but again there is no "standard" for addressing complexity. Simple and complicated are addressed through existing ones, but not truly complex and definitely not chaotic situations.
Good question, and just like Kiron mentioned, Id be careful using the “Best Practices” words.
I agree with Kiron’s feedback in general and specifically point 2, which are to do with dealing with people. I find there is huge gap as well as a gap in addressing soft skills like Emotional Intelligence.
With the new PMBOK edition being in the make and the new ECO, I am hoping that we see those areas addressed as part of the people’s domain.
Both @Rami & @Kiron already send a highly valuable feed back.
It is the right moment from everybody that have a concer on the matter to be part of the revision of the PMBOK that will start on Jan 15th.
Agree that PMI standards do not cover well in the moment the topic of 'leadership' or people related issue, as mentioned by Rami and Kiron. I found that e.g. toastmasters with their pathways tool covering 11 paths to learn about leadership and communication can be a good addition (https://www.toastmasters.org/education/pathways). PMP ECO June 2019 offers 14 statements for PM capabilities, which gives some hope for PMBoK ed 7. Also IPMA's ICB4 describes 10 people related competencies of a PM. In order to learn about leadership, we have to change our behaviors and perceptions, and the toastmasters approach offers in my view the best help because it involves learning by doing.
Regarding the technical PM or process part, I believe business PM (see here: https://www.linkedin.com/pulse/project-bus...hmann-msc-pmp/) is not well represented by the procurement knowledge area and should be extended. Up to 40% of PMs are gig workers or contractors and they, as well as the organizations employing them, need better support.
Secondly, adjacent areas to PM like change management, front-end loading (business case) could use some consideration.
Regarding complexity, which I think is far more than simply Cynefin, a PMI Complexity Guide was developed some years ago (teams from large companies participated, I was a member of the IBM team). See my thoughts on the topic here:
Minor Point: I understand and agree with the principle that project management is situational, and thus the use of the term “best practice” is a misnomer in terms of bodies of knowledge like the PMBOK. However, best practices do exist within organizations and to some extent for industries, which is why I segregated “accepted standards” and “best practices.”
Larger Point: I used the term “accepted standards” generically, as I was trying to refer to any PM body of knowledge. However, I didn’t phrase my question properly, so let me try again:
- What are the “concern areas” in project management that by their nature are unlikely to be “adequately covered” in any accepted standard (i.e., body of knowledge).
I'll stand pat with my three points.
For the first, even if the Sixth Edition and the DA toolkit provide a basis for tailoring, neither can be expected to adequately cover the broad range of project contexts out there.
For the second, there are lots of good advisory references, but few standards.
And for the third, there are models, but no accepted standards.
I see my Canadian colleagues are being politically correct by eschewing the phrase "best practice". I, for one, do not take best practice as an absolute. A best practice is only the best practice at this point in time.
I agree with the previously posted comments. The one I would add is issue management. While the PMBOK guide devotes a whole knowledge area to risk management, it just barely touches issue management. I've been explaining my whole project management career what the differences are between the two. Does issue management merit its own knowledge area? Maybe not. But it sure deserves a lot more than what it's getting now.
Although not directly related to my original question, the topic of terminology is relevant here, as I struggled finding the correct term to use in this question to describe “published standards” generically, as I didn’t want to trigger a sideline perspective.
Take the following terms:
- Standards, Guidelines, Framework, Methodology, Approach, Mindset, Best/Good Practices, Advisory Reference, Model, Body of Knowledge, etc.
Every one of these terms triggers sideline perspectives when they are used, even the more generic ones. For instance, if I used the term “body of knowledge” most people would directly relate that as a reference to the PMBOK (which I didn’t want). And if I had used the term “model” they would likely have viewed it as being too abstract and therefore it would take away from the meaning of my question, and so on. In my question, I modified the word “accepted” by putting the subjective word “accepted” in front of it, to say the following, “a standard that is personally accepted by an individual.” However, I can see why that phrasing took on a different context.
Now, as it relates to the phrase “best practice”: In my opinion, this is understood to be subjective and like @Stephane I can consume such titled works without overt concern to its naming (especially in the context of an individual organization). Would I prefer a different name for the sake of the cornerstone principle that “project management is situational”, absolutely, but that is just a preference.
Terminology -- </aargh :)>
Please login or join to reply